Death of #Agile #PMOT

OK, so maybe Agile isn’t dead yet. But I think it is certainly starting to suffer from the same disease that ultimately claimed Waterfall and other methodologies. As usual, Steve Jobs saw the issues years ago:

Content over process

Process over Content

Once the focus is on process over content, the patient starts to decline. Process is supposed to improve content by providing guidance and predictability. But if the process is followed blindly and no autonomy is given to team members to customize process, we have placed Process over Content. This happened late in the Waterfall days with additional focus on CMMI ranking and achieving other process certifications.

Most troubling is a lot of the discussion is the Agile world lately is about process and not content. We are talking about who is more Agile than whom. We are talking about absolutes as to how estimating is bad and that estimates should NEVER be done. We are talking about absolutes rather than compromises. You are ignoring Content when discussions gravitate toward absolutes. Is it a key indicator that you are no longer evaluating what needs to be accomplished or what value is. The discussion now is darn it, come hell of high water, we will be doing User Stories, with relative estimating, or not estimating at all. And it doesn’t matter what the clients think or what success is.

I know this because people are writing books about absolutes and not about how to compromise.

But Terry, we do listen to our clients you’ll say. We wouldn’t be doing our professional duty if we didn’t promote our preferred approach. We then customize after.

Fair enough. But your preferred approach is all about process and not content. Process enables content, but process is not content. Your focus is on the process….

I’ll let that sink in…

 

My #Agile Breakup

So it has been 11 months now since I’ve seen Agile. How has it been? To be honest, I haven’t missed her. I really haven’t. What has been made clear is what Agile is and what she isn’t.

First Date

I guess Agile and I started dating in 2006. We both were interested in each other and then I was able to arrange for Yves Hanoulle to be the keynote at the Software Development and Evolution Conference I was helping to organize in 2011. Yves had a great presentation on the Agile Mindset that was brilliant. I must admit I only realized how brilliant in the last few months. I think I did what many people have done when they encounter an attractive person coming out of a bad relationship. I moved too fast and fell too hard after being with Waterfall for too long.

The Agile I met was a collection of interesting, valuable methods. There was the concept of the Agile Mindset that Yves and others were promoting with wisdom. But I fell into the same trap as many others. I was going to propose to Agile and she would be the only methodology for me. All projects would be Agile. If clients didn’t like my new girlfriend, then they could go elsewhere.

Agile was a Methodology. I was sure of it. I would exclude using all other methodologies while Agile and I were serious. I would create an Agile Methodology by combining methods and practices. I would read and author Agile papers and presentations where we routinely challenged and chastised each other for not being ‘Agile enough’. I looked for the Agile complement for all waterfall or traditional methods. No matter the project, I promoted the Agile method.

For those of you keeping score at home, the PMBOK isn’t a methodology as well. Similar to Agile, it is a listing of processes, procedures, and knowledge that can be applied. But it is not prescriptive and does not provide governance on how to apply the methods and practices. Many companies take the PMBOK components and create their own methodology from it though.

But what about Scrum you ask? I’d say Scrum is an incomplete methodology. Although it does provide a methodology for the iterations on a project, it does lack guidance and governance in relations to the business case and pre-project intake process. Scrum also lacks guidance for the larger portfolio and enterprise governance concerns.

My Agile Mindset

My mistake was trying to take a collection of methods and assume a methodology exists. A larger mistake was then losing my Agile Mindset of constantly questioning the Agile methodology for value. That is my biggest complaint about Agile now. Many proponents seem to have lost the Agile Mindset of constantly questioning the best method to use on each project. Everyone is just promoting more and more ‘Agile’ methods without confirming that the method returns the most value for the clients. See the No Estimates discussion for this. To blindly promote no estimates for all clients does not represent an Agile Mindset.

I was going to say I’m just as Agile now and I was before, but that statement shows a non-Agile mindset – Agile is not a methodology to achieve. Let’s just say, I feel my projects achieve the maximum amount of value for client by using the Prince2 Methodology using Agile methods and practices were appropriate. Everyone I’ve worked with sees the value in Agile methods and are eager to work with them. The concept that you have to buy the entire Agile Methodology to use an Agile practice is misguided.

I mention Prince2 because that is what we use at the University of Manitoba. You could replace it with whatever you use at your company and then search where you could use Agile methods to return more value. The more I use Prince2, the most I think it is one of the best methodologies I have used though. Highly recommended.

Use an Agile Mindset, Agile isn’t about the Methodology it is about getting better little by little.

 

#Three Deadly Sins of Software Development #agile #hubris

hubris

In my experience, I have encountered three deadly sins in Software Development. Project teams can overcome almost any problems if they don’t fall victim to these three deadly sins. Unfortunately we seem to have progressed through these deadly sins throughout the years as we get more and more experienced in Software Development.

Technology-Centric

Our first deadly sin was the sin of being technology-centric. The first aspect of this was the behaviour in the 1970’s where Information Technology professionals had a belief that they knew what was best for clients and would essentially decide for the clients as to the specific type of functionality delivered. I can remember early on when we still gathered requirements from the users, but we sought no validation on the design or interface. We as professionals know best in regards to how those components should be designed. Even our terminology set the stage for the principle that the business was not informed enough to make decisions on their own. They were only ‘users’ after all. Information Technology professionals would create the system and the business could simply ‘use’ the system we created. Nothing more.

The second aspect of being technology-centric came after we begrudgingly accepted that the business were more than just users and should validate the system design and interfaces. OK, we will let you control that aspect, but Information Technology Professionals will control the selection of all the technology and patterns that lie beneath the interfaces. All of those technology choices must remain with the Information Technology professionals and it would be beyond business users to provide input on technology and patterns selected. Information Technology Professionals will decide on all architecture without collaboration.

Thankfully we now understand that if a technology or architecture is truly better, that should result in more value for the client early and often.

Methodology-Centric

Shortly after being technology-centric, we flowed right into the methodology-centric phase. Alright Mr Client, you define the requirements and value that the project will deliver, but we will define exactly how we will deliver the project. This started out by defining a very specific process for the Waterfall Software Development Methodology, but has evolved throughout the years to be equally specific and constraining processes for hybrid and Agile Methodologies.

In short, any methodology that a project follows without customization for a client, project team, or project is flawed. I’ve always thought how curious it was that Agile proponents once freed of the shackles of Waterfall were so eager to put Agile shackles on every project they saw.

Topology-Centric

And the final deadly sin is one that is a bit recent to the dance, topology-centric. I use topology-centric to refer to the desire by Information Technology project teams to be embedded at a very senior, strategic level for the project. Many times the Information Technology solution can be made better if Information Technology Professionals can work together on the business problem and not just the solution. It is ironic that early on Informational Technology was trying to limit the access the business had to Information Technology components of the project and now the business is in charge to limiting the access Information technology has to the business components of the project.

The more things change, the more they stay the same.

To be clear, the deadly sin is not to that Information Technology is denied access, but rather that Information Technology demands that they should be granted access by default.

Summary

Information Technology Professionals have to remind ourselves we are a service and need to embrace the servant leadership in all aspects of project delivery.  We as Technology Professionals only encounter these deadly sins when we think we know better than the clients. If we avoid these types of Information Technology Hubris, our projects have a much better chance of success.

Turn the Ship Around by @DavidMarquet Book Review #agile #pmot

“Turn the ship around” by David Marquet is a rare gem of a book. It is one of those books that come around once a decade. The book is very well written, provides a lot of lessons that you can apply to your situation, and is very entertaining to boot. In his story of how David Marquet turns around the Sante Fe, we can see similarities to companies, jobs, and teams in our own situations.

It is an inspiring story how one can turn the leader-follower model and turn it into the leader-leader model, even in one of the most seemingly hierarchical situations in the world, the military. I’ve read multiple books now that dispel that myth. I think the military probably gets a bad reputation of being hierarchical, but to survive has probably adapted more and quicker than perhaps any other industry.

Mistake Monitoring

There are many things that you can take away from David Marquet’s book based on what you are experiencing and what problems are foremost in your mind. For me, I was thinking about the challenge of making project reporting more lean and valuable.

So when I read the section lamenting that monitoring in the Navy was just focused on preventing errors and mistakes but not at getting better or more efficient, I immediately saw  parallels with project reporting. I was thinking the same thing about our project reporting. We report about whether the project is yellow or red and what problems we have encountered, but we rarely if ever discuss how we became more efficient or got better on the project. If we are lucky, we discuss those items in the project or iteration close outs. Many times, the items are small improvements and many times they don’t get shared outside of the project team.

It got me thinking, how can we monitor and focus on efficiency improvements on our projects? As Marquet mentioned, the bar is set quite low if success is measured by the absence of errors and mistakes. If success is just based on meeting budget and schedule, are we really trying to improve and get better?  Why wouldn’t team members just provide large estimates so that they were deemed a success. Where is the focus on continuous improvements and wanting to get better? I want to do more on my projects than just avoiding mistakes.

I don’t have answer for where this will lead and what we are going to monitor and share. But thanks to David Marquet we are asking the question to our teams and trying to determine how we can set the bar higher and get better and more efficient on our projects. Maybe that is a good place to start, to say finishing a project on time and on budget is not enough and to ask the stakeholders what other goals and objectives should this project have? And then overall, what goals and objectives should the Project Management Office have?

I’ll report back in a future blog on what we have tried and what have worked.

#Agile Team building by Gary Doer

It was very nice to read a story in the Winnipeg Free Press about former Premier Doer completing his tour of duty as ambassador to the United States. You can find the story here.

Gary Doer

Anyone who knows me knows I am a pretty apolitical beast. There are components I love in every political party’s platform. Truth be known, I am more a centrist than anything. Why then would I say that Gary Doer taught me how to build Agile Teams?

I always saw Gary Doer do three things to build consensus and relationships.

  1. Find commonalities first

Ex-Premier Doer is an accomplished team builder. He perhaps understood people and the power of a metaphor to bring people together better than anyone. Instead of trying to specify a solution or tell people what to do, Gary Doer usually found a metaphor or story that allowed people to get excited about the problem and solution. This metaphor then allowed each individual to interpret the metaphor and find commonality on their own. Many times I witnessed ex-Premier Doer find the only commonality that existed between the two sides and used that commonality to build a bridge to a solution. Usually this resulted in metaphors that were grounded in Hockey or Beer. 🙂 Both are sure to be winners north of the 49th parallel.

      2. No Ego

Gary Doer also had the charisma and modesty to be self-effacing and have a friendly conversation on the issue. He really understood that all progress comes through building relationships and that authority is lost once you have to use it. Never once did I see him upset or rankled, directive or flustered, he was always even keel and building bridges. This lack of Ego really did allow people to understand that he truly was interested in your position and he cared. He also understood he couldn’t just tell you what to do and usually had a suitcase full of facts to share with you.

      3. Walk the middle of the road

Then when it came down to the issue, Gary Doer was always able to walk the middle of the road and not appear overly partisan. (Maybe I have this view because I like the middle of the road) 🙂 But whatever the reason, Gary Doer was an expert in building compromises and solutions in the middle of the road. On a team, you usually have to walk the middle of the road. If you always swing to the extreme of one side of the team, you will eventually lose the other parts of your team.

Summary

I wish Gary Doer all the best in his next challenge. If he needs a new challenge, the political scene in Manitoba could always use another good person. 🙂 Or I could always use a good Agile Project Manager.

#Agile’s dirty little secret

I had the kernel of this blog post a few weeks ago. The idea of the blog post grew and crystalized after viewing Dave Thomas’s presentation ‘The Death of Agile’. It is easily one of the best videos I have seen from an entertainment and educational point of view. I really love watching presentations from people who are simply excellent at presenting. It gives you the same pleasure as reading a book by an author who uses the english language effortlessly.

If you haven’t seen the presentation yet, you can view it at the following link.

Dave makes the funny point of how the Agile movement first had to take a verb and turn it into a noun. No small feat to be sure. 🙂

Presentation Recap

The first part of the presentation is a tongue-in-cheek view of the past history of the business of Agile. It is a very humourous romp through history. Very entertaining and Dave is such a great presenter you really wonder if he is joking or not. It takes us to get to about the 15:00 mark until Dave lets us in on the joke.

The Heart of it

Dave makes the point that we are taking what was a very valuable set of values and degrading it. Dave then states that it is time to reclaim Agility and take it back. Specifically, “It is time to take it back and deny the people who tell us how to do it”

Hallelujah.

There has been so much talk in Agile lately that unless you are doing some methods with no accommodation, you are not Agile. Not doing User Story Mapping? You are not Agile. Don’t have a true flow process in place? You are not Agile. Still Estimating? You are not Agile. Just doing iteration and mini-waterfalls? You are definitely not Agile and should do the walk of shame.

Agile Definition

Dave then gives us the best definition of Agile I have ever seen. He states that Agility is following these steps:

  1. Find out where you are
  2. Take a small step towards your goal
  3. Adjust your understanding based on what you learned
  4. Repeat

Simple. Right?

The hard part is all of us need to take the Agile Movement back from the precipice of being a noun and make it a verb once again. The Agile Manifesto understood this. Every principle had a continuum and action implied. They never said thou shalt never do Contract Negotiation again, but that we should move towards Customer Collaboration. Implied in that is that we should be always moving, improving, and adjusting.

I’ll go a step further. The Agile Manifesto should have a fifth principle added. The first four are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

And I’ll state we should add a fifth

  • Seek to Understand and Coach people over judging and criticizing people

Summary

In short, we need to take a noun and turn it back into a verb. Agile isn’t something to achieve. Agility is a state of mind about constant improvement no matter where you currently are. Some of us are in Texas and some of us are in France just based upon the context of our projects, teams. and clients. We should always seek to understand each other and help to coach them. But always respect where they are first.

This blog post came about by reading Mike Cohn’s blog – “An Interative Waterfall isn’t Agile“.  Instead of judging each other we need to help each other and if some people have just made the step to Iterative Waterfall… well God Bless them..

What does #Protegra do?

I work for Protegra. I’ve worked here since July 23rd, 2001. I’ve performed in a variety of roles and worked on many projects for a wide variety of clients.

But many times we continue to get the question; “What do you guys do?” Some people limit us to a Software Development Consulting company. We often hear “I didn’t know you did that?” Other times people remember we like to do projects rather than resource augmentation.

So what does Protegra do?

We are a consulting company with people who endlessly care to find the ideal solution for the true business problem. Protegra endlessly strives to ask whether the proposed the solution is the best one. Is the suggested problem the actual problem or just a symptom? Can the solution be made better? Is this solution an ideal solution? Our focus is always on solution consulting before solution building. In our opinion, many people jump to solution building before solution consulting.

Have you confirmed you have identified the real problem and have identified the ideal solution?

Protegra solves a client’s business problems through the use of Software Enabled Solutions. Sometimes this is greenfield development, sometimes this is package integration, sometimes this may be mobile development.

The difference is in how Protegra does this. And there are three steps or methods:

1) Protegra uses Innovation Games and other methods to gather Customer Insight as to what the current pains and gains are for the client.

2) Protegra creates Empathy Maps to confirm the true problems and jobs to be done and create and propose ideal solutions to address those business problems.

3) Protegra then uses Agile methods to iteratively deliver solutions to remove the business problems as soon as possible in an iterative way.

When have we done it?

  • We have worked with inventors to realize their visions in a software solution
  • We have worked with government to create and propose a job matching solution in joint ownership with First Nations
  • We have worked with government to determine how we could deliver a Campground Reservation solution in 92 days – Parks Reservation Service
  • We have created a state of the art Payroll and Scheduling system with industry partners – Blue Canvas Group
  • We have worked with clients to find funding for ideal solutions though government grants

We’d love to help your company define an ideal solution to your perplexing problems.