project management - Agile Doctor

1 December, 20159 December, 2015

Agile – It’s All About Making Better Decisions

I’ve been spending a lot of time recently doing research, reading and presenting on human cognitive biases. To the initiated, cognitive biases are defined as

“…a systematic pattern of deviation from norm or rationality in judgment, whereby inferences about other people and situations may be drawn in an illogical fashion. Individuals create their own ‘subjective social reality’ from their perception of the input.” (Wikipedia Definition)

In other words, cognitive biases exist when there is a gap between our perception of reality and objective reality. For example, there is the “confirmation bias” which is our human tendency to seek out or interpret information that confirms one’s existing opinions.

While the term “cognitive bias” is relatively new (it was coined in 1972 by Amos Tversky and Daniel Kahneman), researchers have already uncovered literally over a hundred cognitive biases, some which are relatively tame like the “google effect” (or digital amnesia), where there is a tendency to forget information that can be easily researched, to ones that can lead to more disastrous consequences like the Sunk Cost Fallacy where people justify increased investment in a decision based on prior investment instead of looking only at future efficacy. The Sunk Cost Effect, along with the Overconfidence Effect and Receny Effect, played a role in the May 1996 mountain climbing tragedy, made famous in the movie Everest, that resulted in the death of five experienced climbers.

A great number of cognitive biases have been found through the work of behavioral economics researchers like Dan Ariely who wrote the wonderful books Predictably Irrational and The Upside of Irrationality. Underlying all of classic economics is the concept of homo economicus, or economic man who behaves in rational ways to maximize individual returns and acts in his own self-interest. Unfortunately, this is not the case and humans often act irrationally (and predictably so) because of their inherent cognitive biases. Humans all have biases for loss aversion and would choose to avoid loss over a larger corresponding potential gain and thus act as “homo irrationalis” as discovered by behavioral economics instead of “homo economicus” as predicted by classic economics.

It is our cognitive biases that cause us to make irrational decisions. Since behavioral economists found many of these cognitive biases, it was not a great leap to see how cognitive biases would be a paramount concern for the economics of software development. In my coaching practice, a great deal of my time and effort is used in helping organizations make better decisions about software development. Many times the optimal decisions are counter intuitive to people’s inherent biases so my job (and my passion) is helping companies see the world of software development differently so that, when it comes down to making a decision, they have all the knowledge necessary to make the optimal economic decision.

One of the most prevalent biases in software development is to see the world in a mechanistic / Tayloristic manner. Taylor’s viewpoint was fine for the old world of physical work, but does not hold up in the complex knowledge work being done by software development professionals today. Unfortunately, most of the people making software development decisions are predominantly influenced by this old, less optimal way of viewing the world, and, as a result, make sub-optimal decisions. For example, in the mechanistic worldview, adding more people to an effort results in a corresponding increase in output. If there is an existing team of seven people and we add seven more then we would (if we hold this mechanistic bias) expect the work to be approximately twice as fast. However, like the behavioral economists that found the real world to be counter intuitive to homo economicus, actual studies have found that the need for increased communication of knowledge work nearly outpaces any incremental increase in individual productivity (see Top Performing Projects Use Small Teams). I have always said that if you want to double productivity of a fourteen person team all that is necessary is to create two teams of seven.

The mechanistic bias can also be seen in many of the ways that the Agile philosophy is implemented. For example, the scrum framework is often trained as a series of ceremonies and actions with little or no understanding of the reason such mechanistic actions are successful. “Scrum Masters” are “certified” with only two days of training and a simple test. The training deals with ideal situations, but when the scrum master actually has to implement scrum, he or she is woefully unprepared. In the real world compromises and decisions must be made. Without understanding the underlying “why” of agile and the basic nature of software development, the decisions and compromises that are made are not optimal. In my experience, this is why project managers are tougher to train than people with no project management experience. When faced with ambiguous information and the need to make optimal decisions, project managers tend to fall back on existing mechanistic knowledge and the decisions made range from mildly irritating to completely disastrous. As I have often pointed out, to say that one was successful with waterfall reeks of confirmation bias because it begs the question of whether or not one would have been more successful using another methodology or framework like Lean or Scrum.

In addition to the mechanistic bias, software development suffers from another bias, the project-centric bias, which is the tendency to see all work done in terms of projects. Unfortunately, the project-centric bias is so ingrained in companies that there needs to be some radical changes to the way we view software development across all areas, including accounting. Viewing work as a project when we are actually working on software products results in a whole raft of poor software economic decisions like concentrating on features more than quality and security. Remember that no one washes a rental car.

As I think back on my coaching work in agile, the blogs I have written, the many discussions I have had and the presentations I have made, I think that all of these boil down into one very simple thing – my work is all about helping people understand the true nature of the software development business process and, thereby helping them to make better decisions. Understanding our cognitive biases, therefore, is extremely important for my clients and myself because, in the end, Agile is all about making better decisions.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

22 September, 2015

Real World Agile Q&A

One of the joys of being an Agile Coach is that it is a passion and a calling that doesn’t end at 5pm. Frequently I have the pleasure of staying in contact with individuals who I have worked with via phone and email. With the permission of a good friend, and changing a few details to render our exchange more generic, I present our latest exchange in hopes that people will find it helpful or at least interesting.

Larry,

I keep reading your articles and really enjoy the insight you continue to bring to the Agile world. I’m particularly stuck with a situation here at my current employer.

We’ve organized a scrum team that has done a fantastic job pushing out working, quality software since we started 10 weeks ago. However, this team primarily has worked on our website, but as I see it, we are bringing all of our development work to the team. Consequently, we are about to kick off work for redesigning our Intranet. This too falls into the team’s backlog, but now my business contact is pushing back, saying her backlog for Internet is separate and she doesn’t want to have to prioritize her work including the Intranet. I don’t have the luxury of just adding more developers to an additional team.

What tactics would you use to approach solving this? It’s a fragile situation. Your thoughts?

My response:

Thanks for the kind words. My first thought is a question – how many people are on the team? If you have enough, I would float the idea of splitting the team. The rule of thumb is one or more teams per backlog. What your proxy PO is doing is to (perhaps arbitrarily) split one backlog into two. One team cannot really service multiple POs or multiple backlogs. This way you can give the PO a choice – work with me to understand resources are limited, work with me to value all of the work for the team (not just your work) and then sequence the work so that the entire company is getting the benefit of a stable, focused agile scrum team.

That said, the real root of your problem might be that you really don’t have a product owner in the classic sense. Perhaps you would be well served to find someone who could represent a full backlog, especially if your team is too small to split as outlined above. I would suggest that all stories on your backlog should have both effort (in points) and value. Perhaps the best way to achieve your story value is to have your people compute the cost of delay (COD) for each item. You can then show all the work of the team with respect to value/effort to get an idea of which items to sequence first. If you find stories too granular to perform COD, group them (call them Epics, Themes, etc). Though I don’t recommend wholesale use of SAFe in your case, I would recommend that you have your folks look into concepts like COD and WSJF (Weighted Shortest Job First) that SAFe describes fairly well. Donald G. Reinertsen further elucidates these ideas in the book The Principles of Product Development Flow.

If you cannot get a different PO who can oversee more than just their parochial concerns and you cannot split the team in a way to service the two different products you are working on then your options become even more limited. My next question would be to ask who is in charge of your Agile effort? One of the reasons I have proposed the concept of CAO (Chief Agile Officer) is for situations such as these where someone at the top level of the organization can arbitrate using the entire organizational as a lens to determine best courses of action. It sounds like you are both on the same organizational level so it would help to appeal to a higher management level in instances where two of the same level cannot come to a satisfactory conclusion. Obviously this is a last resort in that people involved tend to react negatively to people “going over their heads.”

I wish you all the best, hope that you are able to resolve this situation and that my advice will prove valuable, and if not so, will at least not result in a negative outcome.

In the end, my friend decided to split the team into two smaller teams. Maybe in a later blog I can follow up to see how well this tactic worked.

16 March, 201519 August, 2016

The PMO is Dead. Long Live the PPMO!

One of the most enjoyable parts of my work and my life is delivering presentations or giving talks to outside groups. During one particular Q&A session I was asked a question along these lines – “If you had unlimited power in an organization, what would be the very first thing you would do to ensure agility?”

My answer, “Oh that is easy. The very first thing I would do is get rid of the Project Management Office.” At which I unfortunately took a pause. The collective gasp from the crowd filled that void and the ensuing murmur drowned out my next statement. You see, I was addressing a PMI group, and my statement proved to be provocative to say the least.

Unfortunately, what the now somewhat irate crowd didn’t hear (or pay attention to) was the statement, “And I would replace the PMO with a PPMO – a Product and Project Management Office.” Contrary to their thoughts that I wished to abolish the PMO, I was actually giving them more – another “P” as it were – a whopping 25 percent increase in letters!

I have railed against project focus other times because it is not a good model when it comes to creating software products. A project has a definite beginning and end whereas software products do not. Of course, software products are sometimes “sunset ” but such plans are often not realized as quickly as proposed. For example, I was once put in charge of “sun-setting” a software product with a timetable of three years. Now, seven years later I am no longer with that company, the company is no longer in that business and yet that old legacy software chugs along, making money for its new owner.

The funny thing about Project Management Offices in software development is that the majority of their work is really on software products. Of course, there are always some projects thrown in, like update the servers to a new operating system, but mostly we work on products whose future enhancements and support live far longer and cost far more than the original bright shiny objects our projects spun off.

The problem is that when we incorrectly treat our products like projects we tend to produce a huge amount of technical debt. Those bright shiny objects come with a huge hidden cost that project mentality allows to remain hidden. When we acknowledge that we are creating products we tend to take care of the long term health of the product, we make better decisions.

So let’s all say goodbye to the old PMO. It had a good run but its time has come. In its place let’s great with open arms the new and improved PPMO!

– Larry Apke

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

17 November, 20141 December, 2014

How I Know You Are Flailing at Agile

As a consultant I try my best to keep abreast of industry trends in technology and software development. Often one of the best ways to observe trends is to check out job boards to see what positions are being posted. For example, job postings can show trends in programming languages. You can see which companies are trying to make Agile transformations (How many big financial companies can hire multiple coaches in Foster City?). You can see which companies have caught the “DevOps” bug and you can tell which companies are flailing and failing their Agile transformations.

How can I tell which companies are failing? When you see multiple posts for the same position over time is a good indicator. For example, you see a post for an Agile Coach that goes unfilled for months. While good ones can be hard to find and take some time, a position open for months can be telling that good coaches are avoiding the company. Most good coaches can very quickly size up a company’s commitment to Agile and avoid those situations where they are likely to fail no matter how good a coach they are. They can sense the fundamental dysfunction. Sometimes you will see a posting one day and the same posting a few short months later. Chances are whoever was chosen didn’t last and that certainly raises red flags.

Sometimes the title that is advertised will show a company’s inherent failure to grasp Agile. You will see a ton of advertisements for Scrum Master or Project Manager. I personally love these as they serve the same purpose as someone wearing a “Stupid” sign in that we know to avoid both. Advertising for a Scrum Master or Project Manager indicates that the company searching understands neither position. The good thing is that if one is only interested in doing Agile then one can save time by avoiding these.

Once I drove nearly two hours for an interview with a company that does only “Agile” projects. During one of the many lengthy interviews, I was asked, “What would happen if we gave you a waterfall project?” “Well for one thing you would not be 100 percent Agile anymore.”

The interview went downhill from there – a waste of a lot of people’s time. Advertising for a Scrum Project Manager would have saved everyone!

Lately I have been seeing another title that gives me pause – Technical Project Manager, especially in the context of Agile companies. I have been a part of and witnessed many abject failures of software development projects (maybe why Project Management should be replaced by Product Management). On none of these have I ever thought that maybe, just maybe, if we had a Project Manager that had more technical knowledge we would have snatched victory tron the jaws of defeat. And the colleagues I talk to agree.

Project Managers have the least amount of authority in making projects successful. A Technical Project Manager is kind of like blaming the weatherman for the rain. It is a silly tactic by management to deflect blame from them. Agile transformation is difficult because it needs change from management and change of culture. Hiring Technical Project Managers is a red herring that distracts an organization from the real work to be done, pushing the transformation finish line even farther away. And finding the kind of person who can successfully straddle tech and management is a tall order, especially when people who know what Agile transformations are all about and who will see through you and realize you are merely flailing at Agile.

– Larry Apke

9 September, 20131 February, 2014

Two Time-Management Techniques to Aid Agility

Originally published on ScrumAlliance.org

With Agile as a philosophy and Scrum as a framework, ScrumMasters are sometimes on their own, left out in the cold when it comes to specific tactics. While I heartily recommend such practices as BDD (behavior-driven development), continuous delivery, and so on, there happen to be some simple time-management practices that I have found to be beneficial for almost all of my teams that have chosen to adopt them.

Team time facilitates collaboration

As every Agile practitioner knows, collaboration is essential to succeeding in Agile so that all parties can discuss the work that needs to be done. To increase collaboration, most of us facilitate grooming sessions with our teams to do things like pointing, writing acceptance criteria, and breaking down epics.

But there is one challenge many of us face: how to effectively schedule and ensure participation.

From my experience, one useful way is to establish “team time” every day right after the daily stand-up. Every day for my teams it takes the form of 45 minutes after the stand-up, which allows us appropriate time to sprint plan, sprint review, retrospect, backlog, story groom, and maybe tell a joke or two.

One of the major benefits is that every team member knows when they are going to meet in perpetuity, so they can more easily find productive time unburdened by a great number of ad hoc meetings. It also lends a very nice rhythm to their day! Since this (and my other technique, outlined below) is agreed to by the team and its efficacy discussed in retrospective, it’s a great example of how a team can maximize collaboration. I have had multiple teams use this technique over the past few years, and I honestly can’t recall one that did not feel it was beneficial.

“Office hours” allow team members to focus and find flow

Veteran ScrumMasters know that individual team members should not be scheduled for eight hours a day. In fact, most know that getting five good hours in a day would make for a productive day indeed! Besides, if you are using the team-time technique discussed above, then you’re starting an eight-hour day with only seven. But here’s the big question: How can I make sure I can get in those five productive hours a day?

In order to ensure that individuals get the needed focus needed to achieve a flow state, one that is necessary for good concentration and coding, most of my teams use “office hours.” These are time slots, decided upon by the team, when they are available for productive work only (e.g., tasks assigned during sprint planning). They will usually schedule a two-hour block in the morning and another three-hour afternoon block in Outlook (if you don’t use that, then you can use a real calendar! No, just kidding).

Not only does this eliminate disruptions but it is compatible with pair programming or other team interaction work when needed. As with team time, it is rare for a team to try this simple technique and then choose to go back to, as one team member put it, “scheduling chaos.”

Stronger together than apart

To summarize, using team time as discussed is an excellent way to facilitate engagement while also ensuring that the team’s rhythm is unbroken. As well, office hours provide a great, chaos-free environment for the team to buckle down, since the time blocks are clearly outlined. While each technique, in isolation, is beneficial for many users, I have found that team productivity soars when the two are fused together.

To see what this looks like in action, take a look at my example spreadsheet below. This will give you a starting point for your own implementation of these two techniques (and maybe jog some of your own inspiration!). I hope that this makes the Agile road easier to travel, because believe me, the journey is worth it.

For additional reading, here are two articles I recommend that touch on this subject:

If you have any questions, feel free to reach out with commenting below or with social media. Thanks for reading!

– Larry Apke

29 July, 201326 October, 2014

Why Project Focused Mentality is Killing Software Development

california damian morys larry apke agile doctor

So, the other day I was listening to NPR in the car (like most people when they listen to talk radio). And the talk was about peace in the Middle East. One of the experts mentioned that, in his opinion, unless both sides owned the process, it was never going to come to fruition. This reminded me of Mark Fritz, international speaker on leadership in today’s organizations, and a compelling blog post he wrote about ownership. I thought this was interesting because there was an interwoven thought he drew upon throughout the post that I believe is applicable to Agile and software development:

“You never wash a rental car.”

I have used a similar phrase many times before when describing the project-centric mentality that pervades most large software development shops. I tell people that, in order to have good quality code, in order to do the right things by the code (BDD/TDD, continuous integration, etc), you must own the code. Therefore, we must move from project to product management, from renting our code to owning the code. So now you know why my brain went from the Middle East to Mark Fritz to rental cars, and now here we are!

Also, I distinctly remember a recent talk when I proposed that in order for better quality products we must eliminate the PMO and replace it with a PPMO (Product and Project Management Office). Interestingly enough, I remember this talk was given to a roomful of project managers who conveniently heard the first part of the phrase and not the second part.

The bottom line is that Agile is about creating high quality software quickly. This cannot be done long term without doing the things that come with owning the code. No project, which merely rents the code, is going to spend their budget making sure that the next group to rent the code has an easier and better time. There is no incentive in project focused organizations to do the right thing! The pressure is on chasing the next bright, shiny object as quickly as possible (e.g: feature chasing) with zero regard for the long term stability of the product.

Before you know it all you have is a big pile of mud that no one can safely enhance or refactor without high chance of regression defects. The time it takes to bring the new, shiny objects to market becomes longer and longer because no one bothered to create the necessary infrastructure. Why not? You might as well ask yourself why no one washes a rental car.

– Larry Apke