Recently I was invited to participate in a focus group by Manitoba Liquor and Lotteries. The focus group was for people who were ‘collectors’ of wine and scotch. For my time I would be handsomely rewarded with a crisp new $100 bill. Naturally I was looking for cameras to see if anyone was playing a joke on me. My only disappointment was that I would not be sampling scotch.
Professional Curiosity
I never have participated in a Focus Group. Being a fan of the collaborative nature of Innovation Games, I was very interested in the methods and practices that would be used by the Focus Group. Initially there were the introduction exercises to get to know one another. The one we used was sharing the memory of our favourite meal – Where did it occur, what did we eat, what did we drink, and who was with us.
Then we did some ‘traditional’ brainstorming on characteristics of our favourite meals. I call this traditional because we all started yelling out ideas. I personally would have welcomed the use of stickies and Silent Brainstorming, but it did work ok as most of our group were pretty comfortable shouting out ideas.
The third exercise and most interesting one was where we had to imagine the ultimate new Liquor Store and then we each had to choose three pictures that best symbolized that store. There were over 30 pictures that we could choose from. Very interesting, the Focus Group was using Metaphors in a similar way as Innovation Games.
Why Metaphors?
So why metaphors? Simply put, metaphors get to the heart of the desires and needs. They get to the important whys. Instead of us throwing out ideas about displays and inventory in the new store, we talked about how we wanted the new store to make us feel. Those requirements tend to be more profound and lasting then whether the shelves are 2 tiered or 3 tiered or whether the red wine should be at the front or back of the store.
In Information Technology I see the correlation in getting the clients to think about the problem first and not jump to solution. Metaphors allow the free flow of ideas and prevent us from prematurely talking about aspects on the solution. It grounds us in the Why and not the What.
So in Innovation Games we ask where you want your company to go and what pains you are currently having. We purposely don’t talk about a potential solutions
It was very interesting to see the Metaphors being used in Focus Groups as well as Innovation Games though. There was more in common than I expected.
Over the last few days I’ve noticed more discussion around the concepts on whether Agile teams should estimate or not. This includes my latest Blog on the subject:
Given the amount of attention this blog has garnered, I felt I needed to provide an opposing viewpoint. The Blog post was very interesting and compelled me to write as I think these discussion points are missing one crucial factor. To summarize, the blog post proposed that these were the 5 reasons why we should stop estimating User Stories:
1) Estimating User Stories is a waste and the time can be better spent elsewhere
2) The estimates will be used for blame and cause the team to focus solely on the deadline
3) Don’t give estimates as these are promises that are hard to keep. In the end they are going to be incorrect anyway.
4) Don’t put additional pressure on the development team and cause them to compromise quality to make the deadline. (similar to #2)
5) The estimates may cause a shift in the project’s priorities due to the fear and uncertainty of large items.
What struck me was what was missing from these reasons for not estimating, namely the client. None of the reasons explained why estimating User Stories created less value for the client. And really isn’t that why the project exists?
Estimates, who gets to decide?
The Client does. Sometimes when reading about Agile principles, I fear we are losing that perspective and we are deciding for the client what has value. The reason I believe in Lean so profoundly is that it provides the focus on why we are doing Agile practices. It helps to ensure that we understand the why of what we are doing at all times.
Let’s review the Blog points:
1) Estimating User Stories is a waste and the time can be better spent elsewhere
Whether estimating is a waste is something that only the client can best decide. Estimating is just another project activity that the client will determine if it is required.
So far every client I have worked with have required estimates at some level or another. Whether or not we think the time is best spent elsewhere is immaterial. The client defines value and the value in their value stream. So far, every client I have worked with has found value in estimates as they need to decide whether the initiative satisfies the business case and whether they can acquire the required budget.
2) The estimates will be used for blame and cause the team to focus solely on the deadline
The fact that estimates can be or may be used for blame is more a comment on a dysfunctional system than a comment on estimates. If estimates can be used in this manner, I would imagine any other deliverable could also be used in this manner. I believe it is the role of a good project leadership team to ensure this doesn’t happen. Not producing estimates is treating a symptom, not the problem.
3) Don’t give estimates as these are promises that are hard to keep. In the end they are going to be incorrect anyway.
Estimates are hard, so let’s not do them. They are going to be incorrect anyway. Let’s just wait until they are actuals and then we can report them and we will have eliminated our risk. But whose risk are we referring to? We have just transferred all of the risk from the project team to the client. If we are professionals in our craft of Software Development, shouldn’t we be able to provide our expert assessment on the situation? If not, why should the client trust us?
4) Don’t put additional pressure on the development team and cause them to compromise quality to make the deadline.
My opinion on this one is similar to #2. This is more a comment on a dysfunctional system than a comment on estimates. The comment implies that the team will sacrifice quality to meet an estimate.
This sounds like another instance of treating the symptom and not the problem. If a project manager is holding the team to estimates and not engaging the client with new ideas, then the Project Manager is probably not the right fit. If the client is doing this, well that is certainly the client’s call. It is after all their solution. Quality for the client may be meeting the deadline.
5) The estimates may cause a shift in the project’s priorities due to the fear and uncertainty of large items.
Valid point. But I think this is the correct behaviour. Large stories will shift the priorities because of the perceived large risk they entail. This I believe is consistent with the principles of Agile to take on these large tasks early to minimize risk and learn fast/fail fast. I don’t think this is necessarily related to estimating. In fact, this is a reason why we need to do estimates. Estimates will ensure we identify the large epics as high risk items and address them early. This will help us to fail fast. If we do not estimate, we may leave these this stories as a lower priority and they will be done later and possibly cause project rework.
Next Steps
One critical benefit about providing an estimate to the client is that it completes the commitment cycle. Typically clients commit budget and teams commit to an estimated solution vision. This estimated solution vision is at a very high level that identifies the features and interactions between the features. It is not big requirements or design up front. But the team should have an understanding of the solution vision before starting or the potential is that excessive rework may be required after a considerable amount of work has already been completed.
In short, preparing that estimates forces the project team to understand and envision the entire solution because we are now committed.
Typically Planning Poker sessions produce estimates, but the real by-product is the consolidated solution vision that the entire team, including the client, has after the session. (In addition to the prioritized User Stories) That is the real value. Not producing estimates leaves the project in much poorer state.
The Guarantee
Why do we believe so strongly in this? Because we focus on the end state or the ultimate Solution. By focusing just on the Software Development process and activities you can Sub-optimize and although the Software Development process can be better (however you define better), the overall value of the project can be diminished or possibly no longer apply. Not producing estimates is one example of potentially many where having a focus just on the Software Development process may adversely affect the raison d’etre of the overall initiative.
Just like outsourcing the act of Software Coding can result in less than optimal solution elsewhere in Software Development, not estimating a Software Development projects can create a less than optimal solution for the entire initiative or business.
Protegra believes so strongly that Agile projects can be successfully estimated that we have an offering to guarantee scope and budget with our clients when we are able to execute Custom Software Development Projects in our Lean and Agile Methodology. It is something we have been doing now for over 10 years.
I’d like to introduce a new feature. The Agile Ask and Answer polls. 🙂 Every Saturday another Agile question will be asked.
These poll’s results will be posted and shared with everyone. Hopefully they will provide some insight into how we all got to where we are, the challenges we had, the challenges we have, and other questions that I wonder about Retrospective after Retrospective.
For this opening installment, we will have two polls.
1) If you could only use four Agile Practices, what would they be?
2) What was you primary role in Software Development when you ‘found’ Agile?
Agile PMO 