As I review proposals from people in the Agile community to push the boundaries of Agile, I believe that Agile is in danger of becoming more and more Sub-Optimal.
Before I proceed, let me just review my definition of Optimal and Sub-Optimal Systems:
“An Optimal system is a system where the optimization of the system or the elimination of waste has been undertaken based upon the value stream of the entire system”
“A Sub Optimal system is a system where the optimization of the system or the elimination of waste has been undertaken based upon the value stream of part of the system. These efforts may actually cause the entire system to be less efficient”
Project Value Stream
Agile has rightly focused on the Project Value Stream and I don’t believe anyone would argue that the Project Value Stream is maximized when executing the project in an Agile manner. But by optimizing ONLY the Project Value Stream, have we sacrificed other Value Streams?
What about the value external to the project? What about the Program and Company value?
Program Value Stream
If I follow Agile by the consensus of opinions I hear proposed most frequently, the following two types of project information are lacking:
Project Memory – Information about how the project was planned and executed.
Solution Memory – Information about the technical or functional solution for the project.
If I use User Stories on stickies, manage via a KanBan board, and my retrospectives, application and automated test cases are primarily my documentation at the end, can I answer the following questions?
- How can I search prior projects for leverage opportunities? Must I read through the code and tests and somehow determine leverage opportunities?
- How can I review prior projects history for a history of how estimating worked so my estimates can be better this time?
- Since we acknowledge that I there is never enough time to create all the automated test cases, how do I know if a new requested change is implementing behaviour that is beyond the intent of the application and will cause downstream effects that I can't anticipate because we don't have an automated test to ensure its correctness currently.
- How can I ensure my solutions are consistent across projects if they don't have high level knowledge of each other?
- Do I have adequate documentation to maintain these applications for the next 10 years if I have a complete turnover in employees?
- How can I manage a department where the reality is that many people will not be able to be dedicated for the lifetime of the project? Do I require more documentation in a situation like this?
By it’s very nature, Agile Software Development projects are silo-ed projects with primarily full-time members and with little governance breaking down the barriers between projects. This causes an even greater need for attention to the Program Value Stream.
Company Value Stream
Perhaps one of the most troubling trends lately is the statement that estimates should not be created anymore as they are bound to be wrong and a waste of time. It is proposed that the project should be started and after two or three iterations the project will be able to confirm the velocity and inform the client as to an accurate estimate on what it will take to complete the project.
This statement is from the point of view of the project entirely. Every project that starts needs to be backed with a business case that confirms that for $X I will return value Y and that is acceptable to the business. If we are not estimating projects anymore, we run the risk of initiating the wrong projects and wasting project money until we determine that the project will either spend too much money or return too little value.
Stating we don’t need to estimate is ludicrous if we truly care about the long-term viability of the company. Implied in my statement is my belief that User Story Points must be translated to hours. In discussions I have had with developers, they have asked for the hours for each User Story as a means for ensuring they were on track. (when I didn’t provide it, they did the math themselves)
Although I like the use of User Stories and User Story Points to estimate, if we do not translate the User Story Points to hours we are Sub-Optimizing. We are placing the development process ahead of meeting the business case. By not giving the developers the context of the estimates in relation to the project’s business case, we are creating a layer of isolation between the business case and the programmers. We are making the project iterations more efficient, but also possibly sacrificing the ability to meet the business case.
And isn’t the business case the reason the project exists?
Three ways to ensure your Agile Project is not Sub-Optimal
- Estimate your project – Make sure you estimate your project and ensure that estimate is incorporated into the Business Case to validate the project raison d’etre. These estimates must be given the care and attention they deserve and not just estimates for the sake of getting the project approved. My recommendation for how to estimate an Agile project is a topic for another day.
- Create Lightweight Solution Architecture Deliverables – Ensure that your project defines the Solution Architecture at a high level and everyone shares that vision of the solution. These deliverables can then be used for project governance and for ensuring consistency and leverage opportunities across projects in a program.
- Translate User Story estimates to hours and track your time – User Stories being translated to hours sets the duration expectation with developers and also provides context back to the business case to ensure we are on track. Tracking time, the bane of everyone’s daily work life actually does have great value for the program and company. Although knowing a project velocity is a great predictor and planning tool, it doesn’t let me know the following:
- What types of work do we estimate poorly or take longer than expected?
- What types of work do we estimate well or take less time than expected?
- What types of work do we forget to estimate?
- What issues do we encounter that add to the time in take to complete a task?
Summary
"Are we sacrificing long-term Enterprise objectives by developing projects in an Agile way?" I don't believe that anyone argues that Agile is not the best way to execute a project. But I do think that sometimes Agile's sole focus on value for the project and the client within the project may cause us to lose focus on the value the Program and the Company requires.
We need to ensure we keep the entire value stream in mind when we are optimizing processes. Otherwise we will have a string of very successful projects at a number of failed companies.
About the Author
Terry Bunio is currently a Principal Consultant at Protegra. Terry never wanted to be a Project Manager. His main career has been in Data Architecture. Along the way Terry discovered that he enjoys helping to build teams, grow client trust, encourage individual growth, doing project work, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Project Manager, Terry is known to challenge assumptions and strike the balance between the theoretical book agile and the real world approaches. Terry is committed to Agile implemented according to Lean Principles.