I have come across many software development teams who call themselves as lean or extremely agile. I generally become curious when somebody says they are lean- are they following the 7 principles of lean software development process or at least a few of the 7. In my experience most teams are fascinated by one principle for sure 'ELIMINATE WASTE'. What they indirectly mean by that is they don't follow any 'mentionable' process.
I used to wonder why one will have to deliberately kill their projects by not following tailor made processes. What's the incentive or what's the deterrent for them? Is that just a directionless leadership or no leadership at all? While the leadership issue cannot be discounted, I found they were having some genuine deterrents that discourage them to suggest or follow processes
- One team had a product owner who changes his mind 5 times in a meeting only to be followed by the 6th time in next day meeting
- One customer doesn't allow the team to understand the product holistically, every day she assigns tasks to team members. Team empowerment is very low and used to do what they are told to do, task-wise. Their morale and confidence is very low
- 'We get only very small customization projects, project ends even before we get our acts together. How can we follow any process?'
- 'Manager doesn't understand and believe our estimations. Before finishing one thing, she asks us to do the other thing- what's the point in planning and estimating or following processes?'
- 'We are a CMM Level 5, so we need to follow all the processes. Nobody knows what value it adds to the product or the customer. When I myself is not convinced how can I ask my team member to follow something?'
- 'We are in the maintenance mode (is that really a project?), customer will ping me in the IM, and I used to give on-the-fly solutions and that's it'
There were more cases and in every case there was at least one valid point. While appreciating and recognizing their hardships, there is something called 'bare minimum' which you must follow if you are doing anything related to software development, in my view. Those are all the first steps that would bring back a derailed agile project on track
I just ask them to follow at least the following whether your manager or product owner wants them or not initially
- Capture at least the high level requirement items (could be a product backlog item or a user story) in a spreadsheet or preferably in a tool like Team Foundation Server (TFS). Detailed requirement for each item shall be discussed and understood with the product owner but a high level description or at least a title for each product feature or requirement item must be available somewhere. Without that list, you cannot prove to your product owner you are adding some value to him
- Assign a owner (from the team) to each of those user stories or product features
- You must break down the requirement, arrive at tasks or work items and they must also be captured somewhere preferably in a tool. This breaking-up of a feature is very important because this is the only evidence that you had indeed planned before you executed. This breaking down of requirement items stimulates the thinking of the developer, the team and the product owner herself. A set of tasks indirectly convey your approach or high level design too. It becomes the communication tool between you and your manager or the customer. If you are working on something, it must imply that you are working on a recorded task. You should not talk anything beyond the recorded tasks in team meetings, mails or other forums.
- Estimate each of those tasks. When you are doing the breaking up of a requirement, the best practice I would suggest is to break down to a level of 4 hours estimated tasks. This ensures you are grounds up and you don't miss anything hopefully.
- Specify the remaining hours for each of the 'in progress' tasks (once per day). This is the only way a product owner can understand the real status. Uttering's like 30% complete or 60% complete doesn't make sense and not a very useful information. 0% completion should be fine, 100% completion should be fine but anything between these 2 numbers leave a lot for imagination which leads to misplaced expectations. Our status reporting should be as objective as possible
- Whenever the task is completed, make the remaining hours as zero and enter the actual hours it took. That should be your timesheet. Possibly your timesheet application takes data from the system- retrieving the tasks and actual hours and report the timesheet and there is no double entry.
- Whenever you change the status of a task or a set of tasks to 'complete', it must be followed up by corresponding code check-in. The code check-in must have appropriate comments and possibly the task number(s) as well. This creates the impression that 'you walk the talk' in the mind of the customer.
- If it's a web based project, setup a staging server and update staging as frequently as possible (once in 2 days). If staging environment cannot be set, encourage the customer to take the latest code as frequently as possible and check the product. Nothing in the world restores the confidence of the customer as the working product does
To me these are the minimum that you must do and this are very basic expectations. By no means this should be thought of as agile or lean because if you are a real one you must do a lot more. These recommendations are for completely paralyzed teams/projects who want to recover and see the light at the end of the tunnel. It will help you to come out a worst possible customer escalation.
By following these steps, you reap the following immediate benefits
- Your team's communication with the customer/product owner improves
- It will be a self-analysis platform for the team to check whether they are really productive
- The customer will think 3 times before questioning the team's productivity
- Approval of timesheet will become a mere ritual, no confrontations are expected at that stage
- Probably you don't miss anything or make any big mistakes because down-to-the-earth breaking up of requirements
- No last minute surprises since the customer is given access to working product from the start and throughout the cycle
- Finally product owner can appreciate what value you added to the product
