Agile Team - 2/3 - Agile Doctor

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.

14 August, 201528 August, 2015

When it Comes to Software Development – Size Matters

Sorry for the tongue-in-check title, but when it comes to software development the size of the teams does matter. When I talk to people about good Agile teams, especially good scrum teams, I talk about five attributes – size, co-location, dedication, stability and cross functionality. I also tell them that if we have to make compromises my preference is to make them in reverse order (ie compromise on cross functionality first, then stability, etc. – not that we want compromise). This means that optimal size (7 +- 2) is the most important attribute. Why is this so important?

One reason is that studies have shown that small teams are much more productive than large teams. One such study was conducted by QSM on 564 projects (from their database of over 4000) titled Top Performing Projects Use Small Teams. I urge folks to check out the entire study, but what is most telling is their conclusion:

To complete projects of 100,000 equivalent source lines of code… they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

In this study small teams were 5 or fewer and large teams were 20 or more so basically you can pay for 4X the number of people, but you won’t get 4X the productivity.

Other studies have shown that as the size of teams increase that the effort for each individual decreases, even when the people are engaged in physical tasks such as tug of war. This curious phenomenon has a name, the Ringelmann Effect. In addition to other things:

Ringelmann discovered that as more and more people are added to a group, the group often becomes increasingly inefficient, ultimately violating the notion that group effort and team participation reliably leads to increased effort on behalf of the members.

According to Ringelmann, there are two main reasons for this effect – Loss of Motivation and Coordination Problems.

The antiquated notion, borrowed from a physical and mechanistic view of software development, that adding people to knowledge work will increase productivity and result in faster software development is still prevalent in many companies, but there are a few software development companies who understand the importance of team size. Amazon, for example, has the concept of two pizza teams. If you cannot feed a team on two pizzas then it is time to split into smaller teams.

The issue of communication (Ringelmann’s Coordination Problems) is alleviated by the two pizza team rule because the number of communication channels increases exponentially as more people are added to a team. This is often described by the equation n(n-1)/2 where n is he number of people on a team. So for teams of 5 (like in the QSM Study) there are 10 communication channels (which is easily manageable) while for the large teams of 20 there are 190! Obviously 190 communication channels is very difficult to manage.

Communication channels would not be a problem is software development was merely a mechanistic activity (as it is all too often mistaken to be), but because software development is a knowledge activity that relies heavily on communication and collaboration, large teams are no a good idea since all the productivity that each new member would bring is easily cancelled out by the additional communication channels (not to mention the attendant loss of motivation).

In my own consulting I have suggested that the simplest way to double productivity of large teams is merely to break it into two smaller teams. My own experience in employing this technique has resulted in a large increase in overall productivity and quality.

As one begins to understand that software development is a complex, knowledge worker activity, one begins to understand that the most important aspect of producing high quality software is communication and collaboration. Communication (and motivation) is optimal when teams are small – so in the end, size does matter.

23 April, 20154 May, 2015

Individuals, Teams, Systems – The Evolution of Agile at Scale

If you have any interest at all in agile, if you read agile blogs, if you follow agile trends, you most certainly have been (over) exposed to one phrase “scaled agile.” I, myself, recently received a certification for one of the new scaled agile programs. While I enjoyed the training I find myself not 100% convinced of its effectiveness.

Perhaps it is because of its very novelty that I remain skeptical. Perhaps it is because I know front line people in companies referenced as successfully adopting who do not agree to the efficacy. Perhaps it is because “scaling ” has simply become the latest excuse from management why agile cannot be adopted at their company (as in why should we bother when agile has not been Provence to scale). In the end though I think the reason that I am lukewarm on the idea is because companies have been latching on to scaling before doing the initial groundwork. in other words, scaling has become a red herring that induces companies to put the cart before the horse or the system before the team.

Once upon a time I coached one of the most amazing agile scrum teams. They were able to deliver things that their management found quite unbelievable so much so that they conveyed a meeting to find answers to why this particular group of people were able to so greatly outperform others in the organization. As an aside I was not originally invited to the meeting but the team lobbies for me to be there as they considered me one of the team and, as a team member, partially responsible for their success.

I remember very well one manager in particular gushing about the team performance and wondering aloud how such a miraculous feat could be “scaled.” “It is very much like the legends of people working together out of their garages,” the manager said, “but how can such a thing” he paused briefly to allow the group to understand what came next would be important, “be scaled?”

Before I realized that the question was merely a rhetorical one to introduce us to the new management buzzword “scaling”, I opened my mouth to answer. “Why we just create more garages,” I said. The answer, which I still stand by to this day, was roundly ignored by aforementioned manager and his manager reports and was about as welcome as a tart in a crowded elevator. What I realized too late was that “scaling” was management’s way of avoiding any action, especially action that might involve hard work and opposition.

So, you might say, scaled agile to the rescue. Not so fast my friend. My amusing anecdote above was all about creating good teams (and creating more good teams). Agile at scale is about creating a good overall system. There is no need to scale agile until you have enough teams doing agile.

Here is the way I like to explain the evolution to scaled agile. Waterfall is inefficient because it tries to optimize individuals at the expense of teams. Good teams have a higher productivity, shorter time to market, higher quality, etc than individuals. Enter Scrum. Scrum, when done correctly, optimizes teams. This is a huge advance and if your agile evolution ended here, you would have come a very long way. Nevertheless it frequently happens that we cam optimize teams at the expense of the system. Once we reach this point it is appropriate to look at ” scaling” and how we can optimize the entire system.

To recap – waterfall optimizes individuals at the expense of teams. Scrum optimizes teams at the expense of the system. Scaling is the attempt to optimize the system. My experience (and it may be biased because like Freud I work mainly with the “sick”) is that companies abuse scaling because they either use it as a means to avoid agile or they rush to scaling without first making the tremendously difficult transition to creating effective scrum teams. My advice remains “build more garages.”

3 March, 20153 March, 2015

The Gang of Four – How Optimization Perseveres

It must be the new year that has me waxing nostalgic again. My last post was of rockstars past and while I was working on that on that one I was also reminded of some others I had a great affection for, a group that I was a part of we called the “Gang of Four”. This was a tongue in cheek nod to the Gang of Four who were authors of a book on design patterns.

The impetus for the Gang of Four was the desire of four agilists to try to do the right things with regards to implementing agile and scrum – to do things that were generally acknowledged as good agile practices but things that were not necessarily politically palatable. In other words, we were something of a clandestine organization. In fact, our meetings, while not in a secret location, were held in a location well off the beaten path – so much so that some of us had to literally walk 15 minutes to get to our meeting room. Over time we added another like-minded individual but kept the original name. Hell, we even had a ironic salute we would give to each other when we would pass in the hall. It was in the company of these wonderfully dedicated people that I spent the most enjoyable time I had on this gig.

What is important and pertinent to this blog is not the nostalgia or shout out to my compadres (though it pleases me to think they might read this and reflect with happiness), but that regardless of your office politics, your cronyism, your brown-nosing, your ladder climbing or your sheer incompetence and general ineptness, there will always (or rather you should hope there to always) be those who will have the uncompromising desire to succeed in spite of your inanity.

Like a tree whose roots will break rocks in order to drink of the water that sustains it, there will be individuals and teams in your company that will persevere against the all odds to do what is right, to do what is best for the company. Seek these out and when you find them give them the environment that they need because if they survive on rocky soil just imagine what they can do on a proper plot of earth.

Long live the Gang of Four.

23 October, 201419 August, 2016

Managers from Hell and Agile Transformation

“Here’s something they’ll probably never teach you in business school: The single biggest decision you make in your job — bigger than all of the rest — is who you name manager. When you name the wrong person manager, nothing fixes that bad decision. Not compensation, not benefits — nothing.”

Jim Clifton, Chairman and CEO, Gallup – State of the American Workplace

A few months back I stumbled onto some research done by Gallup on employee engagement quoted from above. I would like to say that their findings were shocking, but having been an Agile Coach at many large organizations, I find the statistics (and conclusions based on the statistics) to track quite close to my own experiences.

For example, Gallup found that only 30% of all employees in the United States are “engaged and inspired at work” and about 20% are what have been defined as “actively disengaged” employees who “aren’t just unhappy at work; they’re busy acting out their unhappiness. Every day, these workers undermine what their engaged coworkers accomplish.” The remaining 1 out 2 workers are defined as “not engaged” and “essentially ‘checked out.’ They’re sleepwalking through their workday, putting time — but not energy or passion — into their work.”

And take a wild guess what the number one indicator of employee engagement is. You got it – their manager. In another article, Gallup estimates that “companies fail to choose the candidate with the right talent for the job 82% of the time” (Why Great Managers Are So Rare). In other words, next time you are in a meeting with five managers, it is safe to assume that only one (maybe two) were the result of good hiring decisions. If you are a good manager meeting with other managers chances are good that everyone you are speaking with was the result of a poor hiring decision!

The fact that management hiring decisions are so poor should be of some comfort to you the next time you are passed over for the management job you know you can do well, but is little comfort to active agile coaches like myself who are actively trying to help a company get agile and stay agile. On the other hand, knowing this goes a long way in explaining why most companies have so much trouble with the transformation.

Without the support of managers, lasting agile transformation will not occur. The fact that the bulk of your managers are poor leaders just makes it that much harder. Gallup estimates that only 1 in 5 current managers have the abilities to “naturally engage team members and customers, retain top performers, and sustain a culture of high productivity.” Agile is all about engagement. It demands leaders who can engage developers.

So you say you want to be agile? Why don’t you start with hiring better managers? Stop relying on third-party vendors to find your talent. Grow your talent. Recruit your own talent. Find CIOs, VPs, Directors, Managers, Coaches who understand agile, can truly lead agile teams and engage developers.

Go ahead. I’ll be waiting for your call. Of course, it may be a long wait.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

8 September, 20143 September, 2014

“Are You Crazy?!” – Project vs Product Focus

eco-data, larry apke, agile doctor, product focus

When You Have A Project Focus

Coach: If we take some time to learn and adopt excellent software development practices like BDD/TDD, CI and refactor some our code to remove some technical debt, we will be able to development higher quality software and deliver it to our customers faster.

Project Manager: Are you crazy?! We are already behind schedule! We cannot take on anymore work. This would increase our risk of delivering desired functionality!

Coach: But fixing some of these issues will allow the team to create better code and reduce the cost of delivering in the future.

Project Manager: Future. I am concerned with the delivery next quarter. After this project is completed, we transfer the code to the maintenance team. Let them do this work, I don’t want it charged to my project. Besides, the development team on this project will be disbanded at the end of the project.

Coach: Are you crazy?! Disbanding the team? All the progress we have made as a team is lost as soon as you disband the team. You cannot build a quality product when you keep shuffling teams! Keep them together and bring the work to them.

Project Manager: How much are we paying you? We need to save some money.

**When You Have A Product Focus**

Product Owner: That sounds awesome! I will work together with the team to understand the long term return on investment of doing these things, we will create some stories to handle this work and prioritize appropriately.

See what I mean?

– Larry Apke