An Easy-To-Follow, Scalable, Agile Process for Anything

In this article, I outline a quick and easy-to-follow process for getting lots of things done (the agile way).  I think you'll find it useful and informative.  It doesn't matter if you're scheduling improvements to your home, hometown, or business, you can follow this process on any and get results. 

1. Note the request(s) (high level) in the backlog…you don’t have to understand what it is fully…just the gist of what’s being requested.  Make sure you include who its from and anything else.  Make sure it's fluid, too, and always be willing to go all of the way to the end of the process if the rules allow.  Don't let yourself or the process be the bottleneck!
   
2. Backlog and prioritize this work.  Figure out where the request should sit in the queue.  Use a method like FIFO or LIFO as a reference.  You could also create a "value index" to score the cost/benefit of the request.  Sometimes you may choose to do ANYTHING you can just to demonstrate value and show the customer that you are doing SOMETHING toward their objectives.
   
3. Define the request in concrete terms including the problem, required output and success criteria.  This may also include the specific implementation method and input required to get the job done.  Be clear what the customer needs and make sure there's a clear agreement and understanding of output at this time.
   
4. Optionally train the person(s) performing the work—even if it’s yourself—how to do the tasks necessary.  Remember the goals and make sure there is no "loss" in the communication process. 
   
5. Assign the work and start executing.
6. When the work is reported to be completed to spec by the person, verify.  Repeat this step until you accept the quality. Note: you could see all changes you make here as backlog items as well, so beware of "churn" and be fair to the people and process (team!).
   
7. You may queue or hold the result at this time as to efficiently deliver a collection of things to your customers or you may deliver it as well.  Queuing your results will promote longer, larger cycle times but could be more efficient for your business.  Delivering now will shorten the cycle and create for much higher customer interaction, which can be good, especially for very small teams (even teams of one).
   
8. Deliver the result to the end customer.  This is a similar verification (validation?) process but is facilitated by you, the process owner; that way expectations and feedback can be set and the overall process and deliver method improved.

I hope you found this process for getting things done useful and are able to apply it to things in your life.  Please offer any feedback or questions to me through the blog or to eric.veal@efficitrends.com.  Thanks!

3 Keys to Making Your Product Development Effort Successful

Through Six Hour Startup--where a new web-based product is developed and launched by a team of 20+ strangers in six hours--I learned what it takes to lead in chaotic situations. At BluWater Consulting I was Scrum Master to three concurrent software development projects and learned that there are a few key principles required to succeed: strength, (team) commitment, systems thinking, and creativity. Based on this I define agility as “a willingness to seek, accept and integrate feedback as frequently and rapidly as possible”.

In my opinion, there are “3 Keys to Making Your Product Development Effort Successful”:

1. Develop relationships with key suppliers. Rely on your suppliers to coach you on the best tools and methods for your organization and situation. Invest the time and resources necessary to procure what’s required to lead the change you seek! At a minimum, put up a whiteboard to track each project and use “stickies” to track the work as it flows through the process. Ensure that there’s shared accountability within the team and the roles of shepherd, pairing partner, and QA are clear. Synchronize your stickie-note process with a powerful information system so you can get real-time statistics, detect, and analyze process variances.


2. Identify and establish the leadership required. The program will only succeed if you have the support and understanding of the right people. This requires persistence and a strong will! Seek to continuously understand who is in charge (the team) and govern as required. Make the roles of Scrum Master, Product Owner, etc. clear but don’t be surprised when they change.


3. Make sure that your team gets it. There are some critical things that your team has to understand before they’ll do well in an agile process. One example is understanding the difference between burning time “up” (tracking actual hours in the case of work that involves uncertainty or risk) and burning time “down” (tracking how much time is left against work that can be reasonably estimated). Make sure that your team has the training it needs to succeed, move forward, and communicate with each other effectively.

If you would like help getting your project or practice off the ground, I'm happy to quickly assess where you're at and help you get get to where you’d like to be!

Managing Schedule Risk in an Agile Scrum Process

Managing time and the team in an agile scrum project is difficult but it's gotta get done. In all projects, we have to estimate what we're going to do and try to get it done. If we aren't getting it done, we have to either work more and meet our deadline or communicate to our sponsors how things are going to be different at the deadline or move the deadline out. It's all about delivery and customer service in the end. At any rate, typical software projects have two distinct parts, each requiring their own management techniques:

1. New feature development



2. Bug fix, customer service and support

Since we have to manage both of these types of work, and they behave very differently, we need to develop a language around getting things done to support effective communications within the delivery team and to our customer community. The choice we use at my company is Agile/Scrum, where we plan and deliver our work in 2-week increments called sprints. By doing this we're able to execute and significantly re-tweak our process every two weeks. We are given a quote-unquote new lease on life every two weeks; it should be a refreshing way to work and partner.

In our methodology, new feature development is handled by the Agile/Scrum methodology burndown method to track work. The burndown method is the typical agile/scrum way of tracking work: we create a definition of done in terms of scope and features, then estimate how many hours we think it will take to do it. Between the ScrumMaster and the team, we track how the hours are burning (up or down since maybe your last estimate wasn't great and there was unseen work) on a recurring basis and if we think our velocity is what it needs to be. If the velocity starts to slow down, the team addresses how to remove impediments and get the velocity up to such a degree that the project is scheduled to finish on time. If things don't go well, we figure out how to mitigate the risk with the customer.

Burnup is a different but important concept to understand and use to manage our work. Our example of using burnup here is a 50-hour max promise to the customer to deliver customer service. We don't have to provide all 50 hours in our example but we do want to know how much of this time we're spending because it's a distraction to the other part of the project since we can share resources and sharing resources is efficient. This method requires tracking ACTUAL hours spent, which is different from the burndown method. Note that this is a key difference from burndown, where we really only care about how many hours are left. We can see how many hours are left on a burndown type of project but what's potentially left on it is certain, whereas what's left in burndown is only estimated.

These two methods of burnup and burndown are two very different ways to think about work: the former is a picture of what's necessarily remaining and the latter is a guess of what's left. The latter is best mitigated by good planning and knowledge of what tasks and how much time is required to get to "done". Together, we use these two techniques to manage risk and communicate effectively.

Conclusion: We Can Now Manage Projects That Burn Time Up and Burn Time Down

By understanding how these types of work are different and how we can manage each, we're able to develop and speak a language about risk and progress making our velocity increase and our projects more fun.