#Agile versus #Agenda – #Rugby versus #Football #PMOT #JIRA #Sciforma #Favre

We were talking the other day about software products that are used to help the execution of projects in either an Agile or Traditional manner. In particular, the discussion was the difference in models used in JIRA versus Sciforma. JIRA follows the Agile or KanBan model while Sciforma follows the Traditional or Scheduled model. The difference between the two models seemed to be grounded in the concepts of whether planning is done in the temporal dimension. (i.e. have we created a preliminary schedule of when activities or tasks would be done and considered dependencies) In fact, you can’t plan in JIRA temporalily without buying add-on components like Tempo-Planner. (Which is probably where they ended up getting the name from)

Rugby versus Football

First of all, when I mention Football I am referring to the American or Canadian version of football. Sorry european and world Soccer fans.

It then became apparent how good of an analogy Rugby versus Football is for Agile versus Traditional.

There were three important observations:

1. 1. 1. Agile isn’t better than Traditional and Traditional isn’t better than Agile. They are fundamentally different games. The methods and objectives are different.
      2. Although both sports have positions and specializations, Rugby players play in 100% of the game (pending injury substitutions), while Football players typically play 50% of the game. This is similar to Football where there is more specilization and subsituting of players.
      3. And perhaps the biggest difference – Rugby is a game more built on flow and reaction, where Football is built more on set plays that are planned and scheduled. (See where I am going with this?)

The point again should be that the games and objectives are different and that one game is no better than the other one.

Agile versus Agenda

My next thought was if we could find a nice, short term for Traditional like Agile that helped to convey the difference between Agile and Traditional like the analogy of Rugby and Football did.

When we look at the definition of Agile, we get:

“relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.”

It took me quite a while and lot of research, but I think I finally settled on Agenda. Agenda is a term I don’t believe I have heard used when discussing Sotware Development. When we look at the definition of Agenda, we get:

“a list or outline of things to be considered or done“

The important difference here is that an Agenda is a list with a temporal dimension. In addition, an Agenda is perceived to be an initial plan that is to be modified and added to as agreed to. In fact, the first item usually asked in all meetings that have an Agenda, is if the Agenda needs to be modified.

Perfect. Agenda Software Development. Like Agile Software Development, but with an initial planned schedule, outline, and temporal dimension.

Finally a term that conveys the accurate intent of Agile Software Development with a schedule. And that schedule is to be changed, modified, enhanced, and pivoted.

Yeah, Agenda Software Development. That’s the ticket. And in an Agenda Software Development project where Brett Favre, the gunslinger, is the Project Manager. Yea, that’s the ticket.

 

 

Advertisement

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.