#Agile’s Sub-Optimal Value Stream

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 Kan Ban board, and my retrospectives, application and automated test cases are primarily my documentation at the end, can I answer the following questions?

  1. How can I search prior projects for leverage opportunities? Must I read through the code and tests and somehow determine leverage opportunities?
  2. How can I review prior projects history for a history of how estimating worked so my estimates can be better this time?
  3. 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.
  4. How can I ensure my solutions are consistent across projects if they don’t have high level knowledge of each other?
  5. Do I have adequate documentation to maintain these applications for the next 10 years if I have a complete turnover in employees?
  6. 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

  1. 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.
  2. 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.
  3. 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.

My #Agile #Pretotype experience

Two months ago I was introduced to the concept of Pretotyping. If I remember correctly, the introduction was through an excellent InfoQ article. The concept and practice intrigued me and I was able to apply it to a project I was working on recently. This is a recap of that experience in the hopes that is may assist others.

Definition

There is an excellent website that provides some great information on Pretotyping. The site is www.pretotyping.org. The definition of a Pretotype that is proposed on the site is:

Pretotyping[pree-tuh-tahy-ping], verb: 

Testing the initial appeal and actual usage of a potential new product by simulating its core experience with the smallest possible investment of time and money.
There are some excellent examples of how Pretotypes can be created using non-technical deliverables like paper or blocks of wood. But whatever the deliverable is, the concept is to create a deliverable that can be used early on to collaborate with the client on the Art of the Possible and then to confirm the high-level scope and functionality without needing to get drawn into the details.
There is a a quote on the Pretotyping site which I feel adds additional clarity to the concept of Pretotyping.
“We did not invent or discover pretotyping; it’s something that a small number of innovators do naturally. As a matter of fact, our concept and formulation of pretotyping was formed by reading and hearing stories about such innovators and the evolution of their ideas. But what these innovators were doing naturally was not exactly prototyping; it did not have a name and we thought it deserved one. We initially coined the term pretendotype because the most unique aspect of this approach was to pretend or imagine the intended functionality. However, since pretendotype was a quite a mouthful, we simplified it pretotype. The concept of pretotyping is also very close in spirit and practice to Eric Ries’ brilliant Lean Startup Movement and the practice of building the Minimum Viable Product (MVP.)”
In Many ways Pretotyping shares much in common with the Agile Practices of Paper Prototyping and UI Design studio. In fact I would argue that a Paper Prototype or the output from a UI Design studio session is a Pretotype. What I find interesting is the possibility of being able to create a Pretotype technical deliverable (more on what these can be later) that can give the client more of a sense of the solution.
And to be brutally honest, I don’t think some clients would be as accepting of a Paper Prototype as a deliverable. Although we know that the value is inherent in both, some people may see the Paper Prototype as being less professional. The ability to create technical Pretotypes allows for the value to be realized while also addressing any client concerns.

My Pretotype experience

So now that we can see the connection between Agile, Lean and Lean Start-ups, and Pretotyping, what was my experience with Pretotyping?

1. A Pretotype is an incredibly valuable tool to be able to design and perform analysis on the large rocks of value for a project and solution without having to get drawn into details. It was a great tool to stay grounded in what value the client would realize as opposed to the colour schemes, particular fields, and other minutiae.

2. It is difficult to communicate to the client and gain agreement as to where exactly a Pretotype will stop and where Prototypes and other deliverables will continue. Although we tried to state as clearly as possible the boundaries, people are used to Prototypes and find comfort in the detail that exists in Prototypes. My only suggestion would be to continue to over-communicate and continue to discuss the differences between a Pretotype and Prototype. My other thought would be to use the actual term Pretendo-type to more overtly communicate the purpose of the Pretotype. (Some people may assume a Pretotype is a Pre-Prototype, while it is a totally different animal)

3. Although the Pretotyping proponents talk about the ability to use paper and other deliverables for the Pretotype, our clients required a technical experience to allow them to interact with the Pretotype in a manner that is similar to the potential end state. The good news is that there are plenty of great tools out there to create Wireframes that can be used to create Pretotypes. Be careful though, the use of these tools can increase client expectations as to how far the Pretotype may go towards being a Prototype.

I ended up using Iplotz as my Pretotyping tool and I was very impressed with the tool. It was very easy to use and also allowed for the all the functionality I required. Iplotz has both an online and disconnected mode. Iplotz also allowed me to group all my Wireframes into a project and let people collaborate of the project. The suite of controls was also very extensive. I have heard great things about Balsamiq as well. There are a multitude of other solutions as well. I encourage you to review the options and decide for yourself which fits your needs the best.

Summary

Pretotyping has definitely found a permanent place in my Agile toolkit. It won’t fit for every project and client, but I believe it will be something that I will use more often than not.

Is #agile #sub-optimal?

I had a comment that was posted in relation to my Solution Driven Development post that took me on a journey of reading on Sunday. It was a comment submitted by Gebhard Greiter.

To be honest, the comment and its references proposed a more rigourous and prescriptive process that what I prefer to see in my Agile projects. (I’m just not sure I’d recommend that the designer is a separate person than the coder) But I appreciated it’s sentiment. Gebhard, like myself, is struggling to find that correct balance between traditional and Agile processes. I commend him for the principle and strength of convictions, even though my preferences in project execution are slightly different than his.

His proposed balance between the two sides of the methodology can be found here:

Comparing two process models for Software Development

There were also some interesting links or sources of information in the comment. The first one was the Principles of Agility 2011. This link then referenced a Gartner report and quote on the potential downside of Agile. I found the entire article that generated the quote and you can read it at the following link:

Agile Development costs more in the long-term

Is Agile Sub-Optimal?

After I read he article, I had two thoughts. One, that the article drew some broad generalizations and perhaps drew some conclusions I would not have drawn. Two, is the author may be onto a small nugget that has been bugging me for a while.

I’ve always been bothered by the lack of ‘project memory’ if I following Agile by the book. If I use User Stories on stickies, Manage via a Kan Ban board, and my retrospectives, application and automated test cases are primarily my documentation at the end, can I answer the following questions?

  1. How can I search prior projects for leverage opportunities? Must I read through the code and tests and somehow determine leverage opportunities?
  2. How can I review prior projects history for a history of how estimating worked so my estimates can be better this time?
  3. 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.
  4. How can I ensure my solutions are consistent across projects if they don’t have high level knowledge of each other?
  5. How can I easily have new team members support the system? Do they read the code and the tests?
  6. etc….

Active Architecture

I had written a blog post that described my approach to creating Active Architecture Stories as a means to create just enough design documentation so be able to answer half of the questions above. I think the other half can be solved by using one of the leading Agile Project Management tools out there like TargetProcess, Rally, or VersionOne. Any of these tools will allow you to start to build up that ‘project memory’ that can then be leveraged by other projects.

Summary

But the question remains, “Are we sacrificing long-term Enterprise objectives by developing project in an Agile way?” I don’t believe that anyone that argue 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 client may cause us to lose focus on the value the IT Department and the Enterprise requires across all the projects. By its very nature, Agile Software Development projects are silo-ed projects with primarily full-time members and with little governance roles breaking down the barriers between projects.

Sometimes we may need to create documentation that the client does not see value in currently. As professionals we know that there are some documents that will be required in the years following go-live that will pay for themselves 10 fold.

Am I proposing functional specifications? Absolutely not. But I think there is a place for more documentation and some up front design and architecture than is usually suggested. The real question is what documents are required that will ensure I can take advantage of all my re-use opportunities and also be able to efficiently manage the application for the next 15 years.

Perhaps we should also ask those questions when we are determining if we need to create documentation.

Agile Project Estimate Guarantee

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:

User Story Points versus User Story Hours

Yesterday I read the following Blog post on the 5 reasons you should stop estimating User Stories:

5 Reasons why you should stop estimating

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.

User Story Points and User Story Hours

This Blog post may be somewhat controversial, but I really think it provides a viewpoint that I don’t normally see represented. I urge you to read the entire post before jumping to conclusions. Here goes:

The Politics

I’ve read many a good post on estimating Agile projects, but I must admit the discussion about estimating via User Story Points versus User Story Hours seems to suffer from partisan politics. If someone believes in User Story Points, they paint the only alternative as a bleak Orwellian future of accounting for time in 5 minutes increments and shock therapy for the failure of missing estimates. They usually also assume that if you don’t buy in fully to User Story Points, you also don’t believe in Agile in general, Planning Poker, and are an avid fan of Waterfall. Nothing could be further from the truth.

What I would like to have is a bi-partisan discussion of the pros and cons of different estimating approaches.

Disclaimer

Before I start I would like to state that I believe that User Stories, Planning Poker and Story Point Estimating should be done on each and every project. What I am discussing and proposing here is not about not doing Planning Poker and Story Point Estimating, but rather discussing whether the estimating should stop there or continue with other additional methods.

The Continuum

There is a continuum of approaches for estimating. This is illustrated in the diagram below:

When discussing the pros and cons of Story Point Estimating, we are usually limiting our discussions to just the two extremes. I would like to propose a hybrid approach as well.

Agile The Agile approach is the one that is most commonly proposed in the Agile literature. This approach proposes estimating by User Story Points and these estimates are typically generated in a Planning Poker Session(s). The Planning is then done by planning the Iterations based on the number of User Stories and their associated points.Success is then usually judged by being able to achieve a stable User Story Point Velocity from which to execute the remainder of the project in iterations. This Velocity is used in an iterative and ongoing basis to refine the plan for subsequent iterations based on past results.
Traditional The Traditional approach is defined by creating very detailed task level estimates in hours. These estimates may be done by the team, but usually are done without the team or with a subset of the team. These estimates are usually created without the input of developers. The Planning is then done by creating a Work Breakdown Structure. The Work Breakdown Structure is then applied over a timeline or schedule to create the fully detailed Project Plan.Success is usually judged by the accuracy of the task estimates which will then translate into meeting the estimated schedule generated from the Work Breakdown Structure.
Hybrid The Hybrid approach proposes estimating by User Story Points and these estimates are typically generated in a Planning Poker Session(s). The Planning is then done by planning the Iterations based on the number of User Stories and their associated hours. The User Story Hours are created by converting the User Story Points into User Story Hours.Success is then usually judged by being able to achieve a stable User Story Point and Hour Velocity from which to execute the remainder of the project in iterations. The User Story Point Velocity is used in an iterative and ongoing basis to refine the plan for subsequent iterations based on past results. User Story Hours are provided to the owners of User Stories so they know what the original estimates of the User Stories were.

What are the pro and cons of each approach?

Well we all know the pitfalls of the Traditional approach, so let’s not even discuss that approach. 🙂 But why is the Hybrid approach compelling when compared to the Agile Approach? In fact, the Agile and Hybrid approach are very similar except for the fact that the planning is done in User Story Hours and the velocity is measured in User Story Points. In addition, User Story Hours are then provided to the owner of each User Story to provide a frame of reference as to the initial estimate. Let’s look at the pro and cons of Agile estimating concepts and how User Story Hours can help mitigate the cons.

Concept Pros Cons How do User Story Hours help?
User Story Points Minimizes the human element of having duration or hour perceptions influence estimates. May force the ‘slotting’ stories into non-ideal slots. (i.e. It is a 30, but all I have are 20 and 40 slots) Provides a second review once you have converted to User Story Hours to ensure the estimates are consistent and make sense.
Relative estimating Establish standard grouping and increase accuracy by relative estimating. Also leverages human ability to excel at relative estimating. Creates single point of failure. Base line estimate which all other estimates are relative to can create a ripple effect of estimate inaccuracy. This may take multiple iterations to correct. Remove single point of failure with reality check. Second review will ensure estimated hours make sense.
Planning poker Increases team buy in, shares estimating expertise and promotes team growth, helps to refine solution understanding, and increase estimating accuracy. None. Not Applicable. This concept is used in both the Agile and Hybrid approaches.
Velocity and Burn down Validate estimates and plan at a macro level. Not at an individual, user story or task level None. Not Applicable. This concept is used in both the Agile and Hybrid approaches.


Perhaps the most important benefits of User Story Hours are that they allow for the derivation of a project budget and schedule. One of my biggest challenges with the User Story Points approach is the concept that it will take two or three iterations to determine your velocity and then you can inform your client when you can complete the project and how much it will cost. Very few projects I have been a part of can get a blank cheque for two or three iterations and then confirm if the project is feasible and has business value. User Story Hours still allows you to have that check at the end of each iteration AND also create an estimate at the start to ensure the budget and schedule satisfy the project’s business case. Although the estimate still is not ideal, it is better than not having an estimate at all.

And please stop saying that we shouldn’t estimate at all. Just stop, you are hurting innocent people. 🙂

I believe it is disingenuous to propose something as a principle that you know applies to a very small minority of projects. We need more ideas to bridge this reality gap of executing project in an Agile way and requiring project estimates up front to validate a business case.

The Data

I’ve read many posting on the perils of converting User Story Points to User Stories Hours and how a common conversion factor may not be feasible due to the difference confidence factors for each User Story size. I believe this is a red herring. The postings discuss how the conversion factor will be more of less accurate for different stories of different sizes. I couldn’t agree more. And it doesn’t matter.

All we are concerned with is if the conversion factor holds on average for the entire project. I’m not expecting it or requiring it to apply to individual estimates. I’m not holding individuals accountable for User Story Hours for each User Story, as I know these items will follow a Normal Distribution. (In fact the studies I have seen have prototypical Standard Distributions. An excellent post by Mike Treadway illustrating this can be found here: http://the-tread-way.blogspot.com/2011/04/how-many-hours-are-in-story-point.html)

Let’s look at the data Mike Treadway compiled:

User Story Points Average Estimated Hours Average Actual Hours
1 8 6
2 5.5 4.5
3 5.67 5.33
5 5.4 5.8
8 4.75 4.375
Overall Average 5.864 5.201

In this example,converting to and using Estimated Story Point Hours results in an 11.3% difference between estimates and actuals. This is very much in line with the 10-15% project contingency commonly quoted. So it appears that this method is not introducing additional inaccuracy. Please note I am not saying you don’t continue to manage in an agile way monitoring velocity and adapting as you execute. But this would allow for a checkpoint before you start your project that your schedule and budget are feasible. Without this I fear we may give Agile a bad reputation by starting projects that should not have even been started because they did not satisfy the business case.

I also realize that the User Story Hour Velocity will change from iteration to iteration. This factor does not take away from the value of converting to User Story Hours. Trying to use this argument is another partisan point where the argument implies we are going to use the conversion factor to manage in a traditional manner. We are not. We are using the User Story Hours to only plan and manage in an Agile manner. The important factor for both User Story Points and User Story Hours is that we manage by Iterations and at a higher level of abstraction so the individual deviations in estimates are expected and do not matter.

So given the fact that we need to convert to User Story Hours to validate the budget and schedule before we start, why wouldn’t we use them in addition to User Story Points as we manage iterations? I can’t think of any reason but I’d like to hear opposing viewpoints.

Two Final Points

1)      The conversion to User Story Hours is done by the team and changes are only made by the team. There is no Project Management influence to modify the hours. This is absolutely critical.

2)      I’ve heard the comment that providing estimates in hours will affect the developers doing the User Stories and they may alter their behaviour and deliverables. I believe User Story Hours is merely another piece of information that developers should have when undertaking a story. I think having the User Story Hours will let the developer provide feedback immediately if the estimate is incorrect and allow for immediate adaptation. Otherwise we may only find out that our velocity is an issue a week into an iteration. Why wouldn’t we want to know if there are concerns immediately? Developers I have polled have stated they would like to know the initial hour estimate to be able to possibly raise a red flag early. They stated User Story Points do not allow this to be done as easily.

I’d like to hear why people are averse to using User Story Hours and communicating User Story Hours to developers. I’m sure there are some factors I have not discussed.

I think the benefits realized by developers knowing the initial estimates outweigh the dangers of the developers working to those estimates. A true Agile environment and team can allow User Story Hours to be used for good rather than evil.

Please let me know if you find this interesting and whether you would like to see a subsequent post on how you can convert from User Story Points to User Story Hours.

Agile User Novels – A scope tipping point

I was reading an article about how Agile Projects should be estimated, managed and executed and they listed all of the correct items. From Planning Poker to prioritizing stories to determining velocity to working with the clients to define the iterations. But one item I haven’t seen addressed in recent articles is the concept of a scope tipping point in Agile Projects.

Like it or not, there is an amount of scope that is the minimum the client needs for an initiative to be successful. I believe we are not being professional agilists unless we confirm in our planning that we will be able to deliver at least to that scope tipping point. It would be disingenuous to start an Agile Project promising success as we work together if we don’t know that we will be able to deliver the minimum scope required to achieve business objectives. It just isn’t good enough to promise that we will work together on prioritized items until the client decides to stop or the budget runs out.

I like to use the analogy of car repair. How many of us would go into a car shop and be happy at the end of the job if the Car still doesn’t run. I mean it was great that we worked together what the real car repairs were that needed to be fixed and that I was involved in all decisions, but if the tipping point can’t be achieved then it is a waste from a client point of view.

The Car still doesn’t work.

As part of our planning, it is imperative that we compile the results and estimates from planning and propose the Project Novels. These Project Novels are a compilation of the User Stories. These Project Novels can correspond to Releases, but a Novel can also be a composed of multiple releases. The Client and Project team will then agree which Project Novel aligns with the minimum scope required and we will promise that the project will deliver to that Project Novel at a minimum. (I used promise on purpose) 🙂

This Project Novel concept should be used to communicate what stories can be deployed in phases and confirm that where the scope tipping point is. In this way the Client and Project Team agree that we can stop after this point. This is very similar to the concept of Minimum Feature Set and I believe these concepts need to become more ingrained in all our planning processes. I like the Project Novel concept as it somewhat formalizes the Minimum Feature Set concept and makes it a deliverable. I have discovered that the Minimum Feature Set is not done consistently and sometimes not reviewed and agreed to by the client.

I would also recommend that the Project Novel that aligns with the Scope Tipping Point be no more than 2/3 of the way through the proposed project budget. We have to prepare for and embrace the change that will undoubtedly come but still confirm we can deliver what is required at a minimum.

If we start Agile projects without first confirming we can deliver this scope tipping point, we are hurting the Agile movement. When these projects fail to provide the minimum value, they will also blame Agile and the company may be very reluctant to try any Agile Projects again.

Agile Experience Reports – The Agile Dozen

My main purpose for this BLOG was to try and share some personal Agile Experience Reports and get discussions going with others on what worked and what didn’t work. My first challenge was to create a framework where some sense could be made of my personal project results.

When I compiled the list of Agile practices that I feel are important to projects, I was worried about how any patterns could emerge with that many factors. And I was right. I had compiled a list of 42 characteristics and practices that covered the Project Team, Project Planning, Execution, Requirement Gathering, and Development activities on the project.

What I did next was look at those 42 characteristics and practices and whittle it down to 5-10 Agile practices that I believe are really key to project success. Unfortunately, I could not get it below 12. So I was stuck with the Agile Dozen.

Next was the step to validate that those practices were indeed a true indication of project success. And through the projects reviewed so far, they have held.

For my upcoming Agile Experience Reports I’ll share how well we followed all 42 characteristics and practices on a rating scale of 1-5. But I want to caution that I am not viewing this rating as:

  • An Agile scorecard
  • An Agile Maturity
  • An Agile report card

I think those constructs cause teams to focus on the wrong things. Namely, getting a good grade rather than project success, client success, and continuous improvement. I created this framework to help myself understand what practices really contributed most to project and client success and help me to improve and focus on the right practices.

In the next BLOG post I’ll discuss in details the Agile Dozen and my rationale for including them. For now, here is the list of the Agile Dozen..

  • Team Experience (Technical & Domain)
  • Developer to Designer Ratio
  • Embedded Engaged Client
  • Team Continuity
  • Team Estimating
  • Automated Tests
  • Team meeting estimates
  • Daily stand ups
  • Retrospectives
  • Iterative Delivery
  • Epics, User Stories and Product Backlog
  • Continuous Integration

Then I’ll provide some context on where these characteristics existed and practices actually worked on projects and share lessons learned.

I hope you will find this interesting. I tried to find information like this when I was starting out and I could not find it very easily.