Chaos to Order
At the end of 2012, I found that I was on the "bench" for the consulting company I work for. Being on the "bench" means I get paid but I am not on a specific assignment. It is a good time to catch up on training, help clean up 'electronic files' and refresh the resume. After a week of being on the bench, I was pretty sure I wouldn't have another assignment until Jan 2013 (companies don't usually start things at the end of the year), I asked the consulting managers and process managers if there was any work they needed done.
Dad always said "Don't volunteer!" Of course dad was also joking about that.
We have a large client and there has always been a certain amount of chaos in working with this organization. Based on the briefing I got the client was very angry with our delivery and there were fears that they would stop using our services. It turns out this client sends us a great deal of work and we wanted to save that relationship. So I was asked to step in.
When I showed up the very first day and watched what was going on, I became overwhelmed by the level of chaos. The following behaviors were all signs of the chaos:
- Our coordinator was spending an hour at the end of his day putting a list of tasks together to send them to the offshore team members so they would know what to do.
- The offshore team only did the work they were assigned to work on. If they had a roadblock or finished their work they would stop until they got their next assignment.
- The work breakdown items in the client's MS Project file did not match the work described in the tool (Microsoft Team Foundation Server) the team was using to manage their daily work.
- The client was blaming an individual for all the problems and praising how a previous person was perfect.
- The client project managers were so busy that it was almost impossible to have a meeting with all three at the same time
The behaviors manifested in the following ways:
- Each project manager ran their project differently even though they were engaging the same vendor (the company I work for) (Bad thing)
- The work was not broken into small enough 'chunks' (user stories) for the development team to understand and so they implemented the wrong thing or it had a lot of bugs. (Bad thing)
- The client project managers did not clearly communicate the priority of the work and so the teams would be working on the wrong thing. (Bad thing)
- The client did not have a clearly defined set of roles and responsibilities concerning the process. (Bad thing)
- The client did not have a definition for what done meant and so different teams interpreted done in different ways. (Bad thing)
- The client said there process was waterfall but they did not follow their process. (Bad thing)
- Our technical leads tried to fill the 'gap' caused by the client which enabled the client to continue to make the same mistakes and caused our teams to miss deadlines because the technical leads were not fulfilling their roles. (Bad thing)
- The client project managers were using MS Project tasks to manage a team that included members who were offshore (+12 hours offset from our location). MS Project is not dynamic enough to manage individual tasks and developers as the work changes on a day-to-day and sometimes hour-to-hour basis. (Bad thing)
- The client used Project Web Access as a time entry tool. (Bad thing)
What to do first?
The very first thing to do is to listen and observe what is going on. The second thing to do is to ask "Why?"
- Why don't MS Project work breakdown items match, exactly, the names found in TFS for user stories?
- How is the work being planned?
- Are the teams involved in the planning?
- What is the source of truth about the work being done?
- Is there a definition of done that everyone agrees to?
After I found out answers to my initial questions I decided to deal with the project that had the highest visibility and had the biggest team. The very first thing to do was to put together a standard list of tasks that described the work that needed to be completed in order for a user story to be declared done. The next step was to get an initial product backlog put together. This meant finding a set of user stories that were ready to be implemented and stack ranking them by importance.
After this was done we worked with the team to plan two weeks worth of work based on the user stories that were ready to be estimated. I have a capacity spreadsheet which helps insure the team (by both individual and role) does not get overloaded with more work than can be accomplished in the two week period. I will be providing a 'template' of the spreadsheet and how to use it in a future posting.
After that was done I started running daily standup meetings with the team to make sure we stayed on track. By using the capacity spreadsheet I am able to monitor the team's progress in an objective manner. I will ask team members for a commitment to the date they expect to be completed with a task and then I will check to see if they actually finish on the day they say they were going to.
At this point it was a matter of putting into place the basics of an Agile like process. The client is not ready for full blown Agile processes but they can benefit from many of the basic ideas and concepts. Over the course of two months I put together processes, checklists, and training so the client could create user stories, story point, stack rank, build a product backlog, do release and sprint planning and make sure the team continued to meet the planned delivery dates with a variety of tools I provided.
Chaos to Order
- Observe the situation
- Start having daily standups to find out what is going on
- Develop a Sprint Backlog of user stories to be worked on for a single sprint
- Define what it means when a "user story is done" by coming up with list of tasks that describe the work that will be done to implement a user story
- Plan a single sprint of user stories by estimating the hours needed to do each task for each user story
Follow On Actions
- Develop a Product Backlog of user stories
- Stack rank user stories in product backlog
- Size user stories in product backlog
- Do detail planning of the user stories for each sprint
- Hold retrospective meeting for each sprint to help the team improve
- Do release planning
By taking these actions the level of chaos should start to drop to a reasonable level. At least to a level that will allow you to start doing things to improve the team productivity and help the whole organization become less chaotic.