« September 2006 | Main | November 2006 »
October 30, 2006
It's NOT About the Money
David Anderson, on the ScrumDevelopment Yahoo! group asked, somewhat rhetorically:
"Is agile about economic benefit or not?"
I would like to assert, without much to back this up, that agile is not about economic benefit.
Economic benefit is an important side-effect of agile. However, Agile Work is much more about learning, humans exercising creative potential, and value... which is in the eye of the beholder. Agile Work is about people, not abstract things called dollars/yen/ euros/etc. The only reason we care about dollars is because people care about them (certainly a tautology, but you know what I mean!)
I know I might be making a big deal about a little point, but I think that if we forget that dollars are the means, not the end, then we get lost very very easily. Agile is both means and end. It is about doing good work in a trust-building environment. It is about teams aspiring to the best service they can possibly give for their time, not just to be paid, but to derive the satisfaction of having created something that someone else values.
This is why the Agile Axioms are so important. The moment we lose sight of these axioms and start to treat Agile Work as if it was just a set of practices (no matter how effective) is the moment that it becomes un-agile and I no longer wish to be involved.
Now admittedly, as far as coaches go, I'm probably a little on the side of "impose the process and learn" rather than "learn and grow the process". But I'm not at the point of "the process is perfect - thou shalt not change it" and I'm very comfortable working with other coaches who are more on the learn-first side of things.
When Agile Work is applied to software development, it is to everyone's benefit to understand the value of the work being doing. I recently talked about using a financial model. I told the story of how using this tool allows an organization to make effective scheduling decisions. In fact, I strongly believe that the Team should be serving the "customer" and that the focus should be primarily around economic tradeoffs.
But this is just a specific practice. Delivering value is balanced out by self-organizing teams, adaptive planning and a whole host of other practices that are also important.
I'm not the only one who thinks this way. In the book Good to Great: Why Some Companies Make the Leap... and Others Don't
And what happens if you are trying to use Agile Work in a non-profit environment? Then suddenly economics takes a back seat. Does that mean that we can't use Agile methods? Of course not. In fact, it might even mean an easier fit. So much of Agile Work is about culture change: trust and truthfulness, self-organization, learning, getting rid of bureaucracy, balance, etc. Big, command-and-control corporations are probably one of the more hostile environments for Agile Work!
This brings up another interesting experience I had recently.
I was working in the United States for a few weeks on a management consulting engagement related to an enterprise rollout of agile. The business development person I was working with (let's call him Ed) told me a story about meeting with the CIO of a large oganization. The CIO complained about having to spend two years getting rid of the previous "religion" in the company about how to get things done. He was obviously concerned that adopting Agile would put him in the situation of having another religion around.
Ed comforted the CIO by telling him that agile was really just a bunch of common-sense practices. There is no religion of Agile.
I thought about it and realized that I had to disagree! Well... maybe it's not a religion, but it is a belief system.
You have to believe that people have positive intent and that they want to contribute. You have to believe that people can come to agreement. You have to believe that money is not the be-all end-all of life. You have to believe that you can't predict the future. You have to believe that people aren't working only for their own narrow self-interest.
If you don't believe these things, then you can't be agile.
Posted by Mishkin Berteig at 11:07 AM | |
The Wisdom of Teams
I've read a lot of books lately about agile, organizations, teams, work systems, lean, etc. This one really stands out: "The Wisdom of Teams: Creating the High-Performance Organization
Teams also need to develop a common approach--that is, how they will work together to accomplish their purpose. Indeed, they should invest just as much time and effort crafting their working approach as shaping their purpose. A team's approach must include both an economic and administrative aspect as well as a social aspect. To meet the economic and administrative challenge, every member of a team must do "equivalent" amounts of real work that goes beyond commenting, reviewing and deciding. Team members must agree on who will do particular jobs, how schedules will be set and adhered to, what skills need to be developed, how continuing membership is to be earned, and how the group will make and modify decisions, including when and how to modify its approach to getting the job done. Agreeing on the specifics of work and how it fits together to integrate individual skills and advance team performance lies at the heart of shaping a common approach. It is perhaps self-evident that a working approach that delegates all the real work to a few members (or staff outsiders) and thus relies on review and discussion meetings for the only "work together" aspects of the approach cannot sustain a real team. (p56)
Wow! That's about as clear a description of self-organizing teams as I have ever read! I think that that is even more extreme than an agile approach to self-organization since Agile Work sets up some basic parts of the approach such as the Work Queue, Iterations, Team Status, etc. The Retrospective is the relatively limited explicit place where the team adjusts its approach in Agile Work.
The book goes on for several more pages about the "common approach" aspect of real teams. There are examples and other details which constantly resonated with my specific understanding of self-organization.
Posted by Mishkin Berteig at 02:17 AM | |
October 27, 2006
Some Good Links
Mark Levison, a regular contributor on the ScrumDevelopment Yahoo! group and now a student of mine (at the Certified ScrumMaster class), sent me this bunch of links to his blog which in turn link to other great resources. Check them out:
Best Introductions to Scrum (Mark writes:
"I especially like Ken’s video. In an hour he explains the core of scrum. This video is very handy when you’re trying to introduce scrum to new team members etc.")
Posted by Mishkin Berteig at 02:23 AM | |
October 23, 2006
Agile Analysis - Just What is Value Anyway?
Just a quick anecdote: one client I have has decided to use Agile Work to develop the user stories as part of a large project they are embarking upon.
In this meta-project, their team is composed of analysts and some technical people (although not everyone who will be on the development team).
The items in their Work Queue are large functional areas that have been identified. Each functional area could be thought of as a mega-epic which needs to be developed into epics and user stories.
They are using short iterations (I think 2 weeks long) and working on refining their user stories until they can make an estimate on the development part of the project that they are comfortable with.
"Done" for this meta-project means that the user stories are small enough, follow the simple template, and have the INVEST qualities.
At first, I tried to convince this client to do much less work on getting ready and just start the development teams. However, they quite rightly pushed back. They are doing work for a client who has agreed to pay them do develop a good set of requirements and an estimate to go along with it. Both my client and their client are aware of the advantages of early delivery of working software (their ultimate goal), but both have agreed that early delivery of good user stories in a Work Queue is also needed.
Fascinating!
Posted by Mishkin Berteig at 07:55 AM | |
October 22, 2006
Cool Site: Implementing Scrum
An agile coach that I have worked with in the past, Mike Vizdos, has teamed up with an artist to create a web site about agile with a weekly comic strip. This site, Implementing Scrum, has a few comics already there. Each comic examines an aspect of Scrum and Mike provides some interesting commentary related to the comic. Take a look, bookmark it, and check back regularly!
Posted by Mishkin Berteig at 06:50 PM | |
October 18, 2006
Burndown and Velocity Spreadsheet
Jay Conne has posted an Excel spreadsheet tool to use for teams doing agile. The spreadsheet includes a lot of flexibility to account for a single team working with different types of work (e.g. maintenance work). Check it out! This is the link to the burndown and velocity tracking spreadsheet.
Posted by Mishkin Berteig at 01:19 PM | |
October 12, 2006
Edmonton Agile Project Management / ScrumMaster Certification Next Week
Folks, there are still spots left in the course next Thu. and Fri. (19th and 20th). The details including location can be found here. There are only 5 spots left.
Posted by Mishkin Berteig at 11:08 PM | |
Financial Models - Another Form of Visibility
I recently had an eye-opening experience with one of my coaching clients. We were trying to find a way to reasonably have a single team work with several important stakeholders throughout an organization, each of whom had a different project for the team. Up to this point, the team has been time-slicing between these stakeholders. It is stressful work, constantly switching gears. The last time we were there, we started to look at the value the team was delivering to each group. This is where the surprise came.
I was hoping that by building a simple financial model for each stakeholder's project we might be able to find a way to build a proportional schedule for the various stakeholders. Each project would get some proportion of the team's time based on relative value. I was also hoping to eventually roll these values down to the level of individual items on the backlog. I didn't get that far.
What did happen? Well, we did a rough guestimate of the various values of the projects based on the team's understanding. There wasn't anything too surprising that came out of that. We used that now-prioritized list and spoke to the stakeholder (let's call him John) for the highest value project on the list. We sat down with John for about two hours to build a simple spreadsheet financial model.
His project was about adding automation to a fairly long manual process that was used to build stuff for paying clients. We started out by doing a value stream analysis. We wrote out all the steps in the process and it turned out to be about 20 steps. I'm going to keep the numbers simple but representational. Those twenty steps took, on average, 8 weeks to complete. There was very little wait time in the process. But there were lots of opportunities to turn manual operations into automated operations (mostly through the use of computer models rather than physical models).
We also looked at the value for each client request (say $25000) and the number of jobs finishing each month (about 20). This leads to the very nice big number of $500,000/month revenue for the current process.
For each step in the process, we also assigned a time cost in days. This was the average amount of time each step took. By doing this, we were able to assign a dollar value to time reductions in each step. My client had plenty of business and would easily be able to take on more jobs from its clients if only it could do the jobs faster. So by reducing the overall cycle time and completing 21 jobs each month, the company could gain another $25000/month in revenue.
We then looked at all the opportunities for automation in the process and came up with a new time cost for each step. When we did this (and we tried to be conservative), we discovered that we could reduce the cycle time to half.
Doing the math was easy, but it made a huge impact on me. This particular project would lead to a doubling of revenue from $500k/month to $1M/month. The ROI (not counting time value of money) was enough so that the six months of development time that would be needed to buld the automation would be paid for in less than a month!!!
When we looked at the other projects in the team's queue, we saw that none of them would come even close to one tenth the value of this one project.
This huge difference in value makes it clear that the organization has a responsibility to get this one project done asap and likely to the exclusion of any progress on the other projects. The team does have operational responsibilities as well that must be done to keep the business moving, but the priority of new project work was blindingly clear.
Posted by Mishkin Berteig at 11:35 AM | |
October 10, 2006
Managing Process Facilitators - Published on Agile Journal
I've had an article published at the Agile Journal called Managing Process Facilitators (Coaches, ScrumMasters, Agile Project Managers). Please check it out and tell me what you think.
Posted by Mishkin Berteig at 10:33 AM | |