Four Steps Beyond Just Start: Part II: Organize The Work

In my last article I described an Agile assessment.  In that article I framed the assessment as a sprint zero, where the team and a coach would assess the elements of the Agile framework that the team agrees are the most important to adopt.  Moving to Agile is not like turning on a switch, but rather a series of incremental changes that, individually, make the team more effective, and, cumulatively, allow the team to become a healthy, happy, productive and self managing organism.

These articles are meant to serve as sample process sprints.  We may have sprints of work to deliver, but we also have sprints of agile change we want to accomplish, whilst we deliver the goods.

After the assessment, the team will have a matrix of Agile principles that they agree to adopt and strive for. Each delivery sprint should also introduce a new Agile principle or activity. Each activity will improve your teams production and mood.  Sometimes, we might have to complete more than one delivery sprint in order to really nail the new Agile activity or principle.  We decide which new actively to try, based on our teams agile priorities and as part of our team retrospective meetings.  In these meetings, we talk about what went well and what could have worked better.

A common first principal is to deliver working software more frequently.  It is important that we take more frequently not to mean: immediately deliver every 2 weeks.  Delivery times are connected to many variables and the first target should be reasonable and attainable. Perhaps we shoot for moving from every 6 months to every 3 months.  For less complex environments, maybe we can go from every 6months to every 1 or 2.  Before we can commit to meeting that principle, the team, including the would-be product owner, must understand and have control over the work.  Therefore, to meet the principle of shorter release cycles, step one is: Organize the Work.

Organize The Work

First, do you recognize this scenario?  A hard working development team of 7 developers, analysts and a team lead, is struggling to keep up with the to do list.  There is a growing number of items. As fast as they cross something off, there are 10 more and, adding to the darkness, 3 bits that were delivered last week are not working as intended.  Folks from the business change priority everyday, and all have there favorite dev, who they call directly to add to the list or push them to work on their special thing. Sometimes they call around and shop for someone who will say, “yes.”  There are tons of kickbacks, the list is out of control and everybody is sad, or has come to existential grips with the meaningless futility of their plight.  

In order for this group to have a chance to succeed, We must stop the bullets flying over everybody's head, by controlling the work.  This will feel to the team and the business like we are proposing to slow things down even more.  This is addressed with the team and the business with the question; ”Are you happy with the results you are getting now?”  

The answer is likely, “no.”  

Relate to the business and the team, “To make things better we are going to try something, and we need your help.” 

The Plan

1. With the would-be product owners, create a list of features and changes they want, ranked in absolute priority.  There can only be one #1. There can only be one list for one team.  Once you get 20-30 ranked, leave the rest for the next prioritization round.  If the tasks support different product lines managed by different customers, that will complicate things, I will talk about that in Part 4
2. After the list is made, have the team meet and discuss what they explicitly need to do in order to accomplish each task, if the target outcome is unclear, we'll need to bring the business over to clear it up before we get cracking
3. Ask business to be available for questions and, except for emergencies, real ones, don't ask the team to do anything thats not on the list.  We may need to define what equates to an emergency, but it will be important that our interactions with the business are focused on the ranked list, and nothing else.
4. The Team tells us what things can be realistically done in one month.  We can allow some sandbagging in this first round.  Done means: tested, built, deployed and ready for release.  No extensions on the time-box.  You either make it or you don’t.
5. The team meets with the business to lay out the plan.  The key is to get as many things on the list all the way done as you can.  5 things all the way done is better then 20 things mostly done.

If we manage to get most of the list done on time and with improved quality, we will win the hearts of the business.  The next changes we want to try will be easier for business to accept and try out.  I fully agree that the plan is easier said then done.  It will be hard work.

Extra Credit Work

Here are some tips that will help us get the first list done. 

1. Swarm:  have multiple team members work the same issues together.  Work in series, where practical.  Everybody who can help, works #1 until its done, then move to #2.  It is better to get 5 things all the way done, then 20 things mostly done.  (I am totally serious about this)
2. Take blockers out of the way:  If the team gets stuck on #3, Move to #4.  We take #3 to the business to see if we can clarify or propose a solution that the team can meet.  Better to complete what you can, then obsess on a blocker, we can come back for it later.
3. Do a daily stand up meeting, maybe two:  have the team tell us whats done, what they are doing next and whats in the way.  Our job is to get whats in the way, out of the way.
4. Celebrate every thing that gets all the way done.  Draw attention to progress, extra efforts and teamwork.  Stay away from negative pressure like, “If we fail we will never get another chance.”
5. The minute we know we’re not gonna get a task done, tell the business so they are ready.  if we manage to get it done anyway, it will be a nice surprise.
6. Practice the reveal:  have the people who will be showing the work, practice the presentation, best if the would-be product owner is the person showing the work to the brass.

You might have noticed that taking these steps are a good idea whether you are switching to Agile or not.  Good noticing!  Whether you are shooting for Scrum or Kan-Ban, this “organize the work sprint" is super important.

If you need help organizing the work, I can help.  Pop me an email at doug.birgfeld@theagilewave if you like.

Stay tuned for Part III