scrum teams - 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.

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.”

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

27 March, 20133 April, 2013

Philosophy Versus Practice

When trying to get waterfall teams and organizations to move to a more Agile development methodology there are two training strategies – philosophy and practice.

The philosophical approach relies on teaching the history of software development and the philosophy behind Agile – the manifesto and principles. This approach assumes that as long as one is equipped with the proper overriding principles then one will be able to make the correct decisions as challenges occur.

The practice strategy relies heavily on training the ceremonies, especially scrum ceremonies like standups, retrospectives, reviews, etc. This approach assumes that if you do the rights things that overtime the reasons for the practices will become apparent.

Continue reading “Philosophy Versus Practice”

10 January, 20131 February, 2014

Agile = Antifragile Part 2

I entered my previous post on the subject when I had just begun Taleb’s book Antifragile. As I continue my reading I have run into some very specific passages which lead me to theorize that the reason Agile development works so well is that it is a living, breathing example of what Taleb would call “Antifragile.” I am also coming to the conclusion that Taleb is a truly great contemporary thinker. As I examine my own career, I plan to take to heart many of his suggestions on creating one that is Antifragile.

While I am no in any way paid to sell this book, I encourage all Agile folks to highly consider adding this to their reading list.

Continue reading “Agile = Antifragile Part 2”

20 December, 20121 February, 2014

Drive: The Surprising Truth About What Motivates Us and Why Agile Works

In Daniel Pink’s bestseller Drive: The Surprising Truth About What Motivates Us, the author persuasively argues that what motivates people in the knowledge economy (of which software development is squarely seated) “is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and our world. ”

People are no longer motivated by the carrot and stick approach of past Tayloristic, manufacturing, assembly line business. What motivates new workers, and what has been supported by a wide range of scientific studies, can be summarized by the acronym AMP which stands for Autonomy, Mastery and Purpose.

As an Agilist, I am always curious why in one company an Agile implementation succeeds and in another it does not. While there are many reasons for Agile implementations to fail, one thing that many have in common is that they fail to take into account the three factors Pink describes in his book.

Continue reading “Drive: The Surprising Truth About What Motivates Us and Why Agile Works”