Search me out at Agile 2009, or email me…this is great stuff!

Participants in the stand-up answer the standard 3 questions – “What did you do yesterday?”, “What are you planning to do today?”, and “What barriers are in your way?”. At the start of a project, the team have good energy, and are focused on the tasks to be completed. Consequently, they tend to focus on the “real work”, and tell the rest of the team how they are progressing on their task list. Unfortunately, over time the team becomes less focused, and the stand-up drifts into a description of my day yesterday, even if it does not relate to this project. How many times have you been in a stant-up, only to hear person after person say “Well, I was in meetings all day yesterday, and i sent a couple of emails to my boss. I will probably do the same thing today”? Remember, the stand-up is to committ to tasks as part of the team, and help the entire team get to the finish line – it is not a place to whine about how bad your day was (or is going to be), nor a place to simply give a status on what you are doing.

So how do we make sure we remain focused? Funnily enough, I have the answer for that!

Do you remember the task board? The source of all project and iteration knowledge is the key to effective stand-ups.

During the stand-up, I encourage (OK, so sometimes I insist…) that whoever is speaking goes to the task board, remove the task they completed and move it from the “In Progress” column to the “Complete” column, and while doing so talking about anything significant they think the team needs to know about during their work on that task. Then, they remove a task from the “Not Started” column, and move it to the “In Progress” column, describing their plans – and any potential issues – for completing this task. Typically, this takes 60 to 90 seconds…and is very focused and meaningful. Every team member who is completing tasks on the board should do this in turn.

But what about the participants who do not have tasks on the board? Well, I would argue that if they are doing work on the project, this work needs to be related to a user story, and therefore has tasks to be completed – the board is not only for technical tasks, but for every task that needs to be completed for the project to be successful. And if participants do not have a task on the board, they can still give a brief decsription of their actions if they want to, or simplay “pass”.

What happened yesterday to get me thinking about this? In the stand-up (I recently started a new engagement, and am about a week into it) I asked team members at the end of the stand-up to step up to the board, and update their tasks. My word, a lot of paper was moving, and some meaningful comments about each task was made. Afterwards, several people asked me if this was “normal”, for people to move their own tasks around (“Of course” was my answer). We tried it again today, and the stand-up was completed in 10 minutes, but was very focused. Now my challenge is to sustain this practice.

The task board is an integral piece of the daily stand-up – make sure it is used, as it will help you stay focused, relevant, and fast!

All three organizations had problems that fell into very similar areas – requirements and iteration execution.

Nobody in any of the organizations had bothered to collect any requirements, but has simply talked with the users and started coding. They believed that this was Agile – after all, if you don’t write anything down, you don’t need a change management procedure, and you are always working off the latest version of reality! This was a reaction to the strict requirements document needed for projects prior to implementing “their” Agile methodology, so maybe it is (a little) understandable - but still wrong!

When it came time to execute an iteration, the list of things being done poorly was huge! For example, the development team would agree on the (non-documented) features they wanted to work on in this iteration. They would invite the users to meet with the team for about an hour, and listen to the users as they told them what they wanted. The development team would then start coding, using their experience an judgement to “do the right thing”. At the end of the iteration, they would figure-out what they had completed, then pass this to testing (testing in all three cases was not integrated into the software development effort). Whatever they had not managed to get to would be carried-over to the next iteration, when the process (or lack thereof) would start again.

 Two of the organizations had read Ken Schwaber’s books on Scrum, and one of them had read about it on the web, but nobody had any training or prior experience. Hardly a good basis for changing to a new development methodology, despite the clarity Ken brings to the process.

When I asked about the elements of Scrum they had gleaned from Ken’s writing, I was told that they didn’t think that all of the elements described by Ken were necessary – the stand-up meetings were too frequent, the planning too complicated, and nobody was interested in anyting like a retrospective! Oh, and measuring what you accomplish on a task level – not a chance, it takes too much time!

Agile development relies on a simple premise, but there are some vital underpinnings in making it work. These three organizations were in anarchy, and were NOT Agile. Will the developers in each organization ever understand, and accept, this? I don’t know, but I do know that the management of one of the organizations has already “had enough”, and decided to return to their old SDLC.

What a frustrating week…but then this is what I get for being an Agile advocate, I guess!

I firmly believe that both the scope and the requirements need to be flexible – indeed, the scope MUST be flexible, allowing to it to expand a little in one area, and contract a little in another. If we do our job properly, the size of the scope remains pretty much the same, but the intent of it moves a little in one direction, leaving some things behind, picking up new things as the business changes. Similarly, we need to be very flexible with the requirements – we need to drop some, need to add some, need to redefine others, re-order the priority, and so forth.  I seem to spend a lot of my time coaching clients in a different technique from the traditional one described above, and which provides them with .

Typically, I hold a kick-off meeting to define the business case for the project – a high-level understanding of what the solution is to do, how it will fit into the clients business, who will use it, how it will be deployed, and defining any technical issues surrounding the solution. I then break these into several key areas – for example, data entry, data feeds, reporting, and user security – for further definition. To accomplish this, I use something I call a “2-2-1” method – 2 hours of requirements definition in a specific business area with the Product owner and business team, followed by 2 hours of analysis and refinement of these requirements by the development team, and 1 hour of review by the development and business teams of these requirements.

Following the kick-off meeting, I can produce a schedule for these 2-2-1 sessions, as I know how many specific requirement areas there are, and each one takes 5 hours to define. Time-boxing these meetings is essential, as it focuses the end user team and the development team in accomplishing the goal of the 2-2-1 session. I am always amazed how much work gets done in the last 30 minutes of the first couple of these sessions!  

During the refinement (the second 2-hour session) session, we will produce screen designs, technical design documents, report layouts, and other artifacts to provide hands-on feedback to the business team. Additionally, we can produce a high-level estimate by using the business and technical complexity characteristics of each element. 

Once we have completed the first few 2-2-1 sessions, we can start constructing the first release plan for review with the customer. Following the acceptance of a release plan, we can determine our iteration plan, and from there a work-plan for the first few iterations. Once we get to the item level in an iteration plan, we can estimate very accurately, although the estimating model is somewhat different from many tradition estimates. Based on the release plan, we can determine how much time we can allocate to completing the development effort, from which we can determine how big the team needs to be, from which I can develop a budget for this effort. As we are taking an iterative approach to development, the real question is not “how much will each iteration cost?”, but rather “how much – and what – can I complete in each iteration?” followed by “How many iterations will this take me, based on everything I know right now?”. 

Now, here is the magic – the requirements (as we admitted earlier) change during the engagement, and we deliver something the user can use at the end of each iteration. At the start of the next iteration, we re-evaluate what goes into the upcoming iteration before we start it. During this re-evaluation meeting, we have the opportunity to run another 2-2-1 session, to fully flesh-out the requirements for this particular iteration. Oh, by the way, because the iteration is short (2 weeks or so), I can be incredibly accurate as to what I can fit into this iteration.  Using this approach, we eliminate the need for a change control process – changes are made prior to the start of each iteration.

Similarly, the scope will move, but the customer will always be in control, as we are determining what we can do in each iteration against the release plan. As the decisions for each iteration are made, we can compare it to the release plan, and highlight the differences with the customer before we start any construction. This lends itself extremely well to metrics-based project management. We have a good idea of how big the entire project is at the start from the estimate we developed, we have a better idea at the size (and cost) of each release, and we can provide reports to the customer on what each developer is doing at the task level during each iteration. As the engagement progresses, we can measure changes to the release plan against the baseline from the start of the project, we can accelerate the project by adding resources, we can remove features if we are not going to hit key dates, etc. 

This all, of course, rolls very well into execution, too, as I have an iteration plan to execute against, with tasks from this plan being assigned to team members. A daily stand-up allows the team to commit to executing their tasks, ask for help in getting their tasks done, or accepting new tasks if they have slack time. If this sounds at all like Scrum, it is because the execution IS Scrum – I find this simple for clients to grasp and use in a short period of time. Maybe I will deal with introducing Scrum into a traditional organization in a future article…

My name is Paul Ellarby, and I have been practicing Agile and Lean software development for many years…in fact, I was trained as a mechanical engineer, so when I started developing software, I used many of the design and development techniques I practiced when I was developing machine tools for the automorive industry – design, develop, deploy, adapt. That was in the mid-1970′s. Since then, I moved from England to the USA (in 1981), and have been involved in the custom software development space since then. My wife and I ran our own custom software company – ITFirst – for almost 10 years, until we sold that business in mid-2007. I spent the last two years at ITFirst coaching and advising clients on Agile and Lean software development, and continue in this advisory capacity with my current employer, Daugherty Business Solutions, where I lead the Custom Software line of service for the Minnesota office. Naturally, I run as many of our projects in an Agile manner as I can, introducing even our most traditionally-oriented clients to these techniques.

As this blog grows, I will introduce various topics and things I have learned, and comment on activities and trends within the Agile and Lean communities. Above all, though, I will try to have some fun, and hope you will comment on my opinions!