More on Scaling Agile
Sunday, November 12th, 2006One problem with having multiple teams working on the same project will be the tendency to compare the teams’ performance. Why is this a problem?
One problem with having multiple teams working on the same project will be the tendency to compare the teams’ performance. Why is this a problem?
Your developers have just planned a two week iteration. The next day Sarah continues her work on the completion of an important New Project. And here it comes - Urgent Stuff…
More and more, organizations are applying agile methods to large projects or efforts that require more than a single team. There are three dimensions or concerns of coordination. It is critical that all three be addressed, but there are many ways of addressing them. Here I will simply list these three types of coordination and make some simple suggestions of how to implement them.
Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is “right” is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.
I’ve been researching the requirements and variations on the Product Owner Role for a client that I am assisting. Here is a small collection of links and notes.
Updated (Originally posted Nov. 18, 2005).
Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.
Give self-managing teams:
authority
space
safety
Most of the teams and organizations I coach are working on using agile methods to improve their software development approach. Somewhere along the way, someone has realized that there must be a better way… either better than chaos, or better than bureaucracy. Over the years that I have been practicing agile methods, I have come to believe that quality is not negotiable.
The Process Facilitator has only a few key responsibilities. One of those is to remove obstacles that are preventing the team for completing its work quickly, effectively and with high quality. The team’s primary tool for tracking this work is the Record of Obstacles. Like the Work Item List, this is a fairly simple artifact.
(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)
We recently had the disconcerting experience of having a client cancel our engagement because they’d felt that we weren’t being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.
In agile development circles self-organizing teams are all the rage nowadays. And I often hear people bemoaning the “evil managers”. And no doubt in many circumstances and organizations there is real work to do here and real dysfunction to resolve. But I’m less concerned with the analysis of what’s wrong and more concerned with what can we do differently and better. IE: How can we develop the skills necessary to practice effective self-organization.
So what does it mean to be a participant in a “leaderful” group?
In software development (and in many other types of projects), there is a typical non-agile approach to estimation of project size. This method starts with a high-level understanding of the work to be done, the requirements, and uses that to make an initial estimate of the project size. This estimate is often stated in units such as man-months. There is a very important piece missing here that makes this estimate completely useless… that makes it pure fantasy.
Agile Work requires only a very small number of simple “artifacts”. The most basic is the Work Queue. This is very similar to the Scrum Product Backlog but there are some differences too. The Work Queue is like a carefully managed To-Do list. This article details the use of the Work Queue.
In Blink : The Power of Thinking Without Thinking by Malcolm Gladwell, there is a chapter that describes a number of fascinating experiments. These experiments show how we can be influenced by very subtle cues in our environment. This is a very important lesson for us to apply in our work environments and in particular in our agile work.
I recently completed reading An Introduction to General Systems Thinking by Gerald M. Weinberg. Since it was mind-blowingly fantastic, I thought I should probably write a brief review of it so you-all can check it out!