Would you like fries with your McApplication? #NoEstimates

There is a great difference between a fine meal and McMeal. The fine meal typically has been crafted with years of experience and training by chefs around the world. The McMeal is put together with years of experience based on what people want at 1:30 am in a drive-thru. The fine meal also places forethought as to how the components work together and play off of each other. With McMeals and other fast food meals, you are left to your own devices as to what you would like combine together at the last possibly moment.

Software Development

Similarly, Software Development can create solutions on which great experience and effort is expended determining how the components fit together or we can slap the functionality together for a McApplication. Agile can and has been guilty of creating too many McApplications over the years.

User Story Mapping

User Story Mapping is a great tool, but unless it is followed up by some analysis and design work to architect the solution, we are just visually drawing the new McApplication. While the concepts of delivering in iterations and visually planning the iterations is extremely valuable, jumping into delivering without architecting the overall solution is misguided and sub-optimizing.

If your first project work is cutting code after you have created a User Story Map, you are well on your way to creating the next McApplication.

We always need to remember we are professionals committed to creating, designing, and delivering the best solution to a business problem, Sometimes this may involve providing counsel to clients on why some stories should not be done, why some stories should be done later, why some stories need to be done now, and why some stories that they haven’t thought of need to be added.

Client priority rules the day of course, but if we just do what the client identifies without providing our expertise, we are no longer professionals. We are just order takers.

To avoid being just order takers we usually need to do some detailed analysis on what a story means and how it needs to be implemented. Just capturing the highest ‘placeholders’ to discuss functionality means you are creating your architecture as you go along. Yipes.

NoEstimates

Which brings us to #NoEstimates.

No Estimates does not focus on creating a better solution. No Estimates has been created so that the project can be forecasted. It proposes nothing to help create a better solution to a problem. Even worse, when No Estimates is followed to the letter, it can even absolve the team of project leadership duties.

No Estimates proposes that we will just work on what the client wants, when the clients wants it and we will stop when the client wants to. It overlooks a key responsibility of project teams to save the client from themselves with our experience and expertise. Agile sometimes seem to shy away from tough discussions that should happen early on projects. Some projects should never start.

Agile proponents forget that not only should code to tested early and often, but incorrect client concepts should also be. If we are taking direction on a client priority that we know is wrong and will result in a lesser solution, and we haven’t done everything we can to change their mind, then we are not Agile.

No Estimates proponents will probably state that all those things should be done on a project in addition to No Estimates, but by not putting design and architecture front and centre it is clear they primarily value forecasting.

Due to this, the type of solution you will get out of a No Estimates projects will probably be a McApplication rather than a fine meal and you’ll probably be hungry for a new solution before long.

Solution Leadership and healthy adversarial discussions over difference in opinions is not valued highly on No Estimates projects. The focus is on ¬†forecasting and doing whatever the client want to do next….

Would you like Fries with that?

 

 

 

#Scrumbled #Agile or #Disciplined #Agile

So I attended a Scrum session last week that was presented by Steve Porter. Excellent session that discussed many of the misconceptions or myths about Scrum. I came away wondering why I don’t profess to believe in Scrum. I honestly do follow many of the Scrum rituals, but I always seem to not be able to follow them completely. The processes I use always seem to be a Scrum-but implementation. I do Scrum except for this customization, I do Scrum except for this circumstance. Many of the myths we reviewed also seemed to be focusing on small misconceptions of what Scrum is. Not the large issues that could really derail a project – this frustrated me.

For example, we discussed whether the iteration planning should be 4 hours for a two-week iteration. My response is that it is nice to have a guideline, but things will take as long as they take. Sometimes we need to change based on the team and the stories.

Honestly

To be honest with you, the one thing that has always bothered me about Scrum is the amount of time, effort, and care that focuses on the rituals themselves. There tends to be great detail in how long meetings should be, how long iterations should be, what a Product Owner should do, and what a Scrum Master should be. Early on for Agile projects, I think this type of direction can be quite helpful. But Scrum has always struck me as being overly precise and prescriptive. In many situations I would prefer a loose guideline that would provide me options as to how I could structure a project. It really feels wrong to try to control an Agile project to the extent the Scrum process does. I would much rather just allow my team to customize the process as they see fit.

One thing that resounded with me after reading “Creativity, Inc.” was the comment that to nurture a creative culture, we need to “hold loosely onto goals and firmly onto intentions”. If you allow me some creative license, I believe this can be translated to than we need to “hold loosely onto rituals and outcomes and firmly onto values”

Stated in this way, it becomes clear to me why I struggle with Scrum.

It always seems to me that Scrum places rituals ahead of values. Instead of focusing on values and discussing a variety of approaches, Scrum doesn’t spend enough time discussing values and spends more on the details of rituals.

To me it seems we have Scrumbled/Scrambled what Agile should focus on.

What to do?

Recently I’ve become more aware of Disciplined Agile. I believe it has great value that is not found elsewhere in the Agile Ecosystem:

  • A Decision Framework that provides a structure on how an Agile project can sit inside the Enterprise and doesn’t just focus on the Software Development Team
  • A Decision Framework that allows for the customization of the Agile project process based on the readiness of the Enterprise and project team. Disciplined Agile supports the following Agile processes:
    • Agile Delivery
    • Lean Delivery
    • Continuous Delivery
    • Exploratory
    • Program Management
  • A Decision Framework that provides a prioritized list of rituals/deliverables to use though out the project
    • This allows for the project team to choose and adapt to what fits best in each circumstance
  • A home for an Architecture Role on the leadership of an Agile Project
  • A Decision Framework that provides the right focus for lightweight models/documentation through out the project

I’ll be focusing on Disciplined Agile over the next few Blog posts. It has great promise in helping Agile take that next step into the Enterprise.