Radical Management

I just finished the book "A Leader's Guide to Radical Management". This book argues for expanding and implementing iterative and transparent management techniques across the entire organization. So, it is one of any number of methodologies and philosophies that argue for proliferating the principles of contemporary software development techniques found in Agile Scrum to a broader application.

If you are familiar with Agile/Scrum, much of the "radical" techniques will be very familiar. This is especially true about the long list of practices that are suggested at the end of each chapter. Nothing really new here.

The main premise of the book is about identifying clients and focusing on pleasing them. Clients do not have to be external customers but are also internal groups or departments that consume the output of another group or team.

There is lots of good wisdom about team leadership, transparency and client-focused operational techniques that is communicated through anecdotal stories throughout.

Overall a decent read, more interesting if you are not at all familiar with the concepts.

Agile Update

We completed our third Agile iteration last week. Each iteration we've done has been a bit different from the other. Our first goal is to simply learn to iterate. It sounds so simple, right? Just agree on a set of work to try to complete within a 2 week span and get on with it. For the most part, we have been successful at a basic level. Each iteration has started on a Monday and ended the following Friday. However, some observations are worth mentioning.

First, the background of the team was minimally controlled anarchy. It was an approach that has taken them very far. For most of the past history the team has been very small. We have grown the team by 2 or 3 new members over the last several months. The total is 9 developers, 2 test engineers and 1 technical writer. It is a good-size team for experimenting with Agile.

Before starting the first iteration we had trialed and adopted Rally as an Agile project management tool. Having this tool in place made it easier in many respects to be more successful that if we had not done that. For one thing, it allows us to be a "little" Agile in that we actually work more like an iterative development team with very short iterations than a true Scrum or XP approach. Adopting one or both of those approaches would have been a pretty radical culture shift for the team.

The first iteration felt a little frazzled. Some team members were stressed about getting everything done in 2 weeks, even though we had carefully scoped the work to fit. The additional urgency around actually committing to being done at the end of two weeks added energy to the team. Also, there were lots of questions about how to handle process-related things that came up. We learned a lot about Rally and how to use it to enable more efficient communication paths.

The second iteration felt a little more natural. We accepted a very high percentage of the work we had set out to accomplish. There were many less questions along the way and we adapted some of the practices we tried in the first iteration to be more natural in the second.

The third iteration was completely different. First, we started with much more committed work. We ended up only accepting about 45% of the work by the end of the iteration. That was good in that we learned that we can push work if it is not done and not feel too badly about it. Our average productivity over the 3 iterations was respectable. Pushing so much work into the next iteration renewed a commitment toward really being "done" with a story and not just chopping it up to make it fit within an iteration.

We had our first retrospective this past Monday at the beginning of the fourth iteration. The comments from the team were focused on how we get better at doing iterations. One common theme was the desire to do better at transtioning from one iteration to the next. Suggestions for a demo/planning day at the end of the iteration and more time discussing the stories at the start of an iteration were voiced. This will probably be the one thing we work on in this current iteration.

At this point our focus is on using iterations as a synchronization mechanism. We are not having daily standups (although we do send daily email status reports to the entire team with the same format as Agile standups). We do not do a good job of grooming the backlog and having stories fleshed out before we start the iteration. We are using an adjustment in "points estimation" that couples us a little too closely to concrete ideal time estimates. We also have to react to changes mid-iteration due to customer demands or whims within the company.

These are all things that need to be addressed over time if we are successful at getting real buy-in from other departments in the company.

Scaling Agile Out

Even though we are just starting to incorporate some Agile techniques into our team's approach to building great products, I am keenly interested in the notion of scaling out across the company. I believe that Agile thinking is a head-on approach to embracing change and a natural way of increasing discipline at a number of levels. However, it requires flexibility and customization to the specific company culture and environment. Starting at the conceptual level and following principle is more important than mechanical adherence to recommended practices.

That said, some things are not negotiable. Two principles that fall into this category are rhythm and planning. These two principles are directly related and influence each other. Rhythm levels include daily, weekly, iteration(sprint), release, roadmap(see dissenting opinion) and strategic vision. Planning categories should include the same time spans. What are we doing today, this week, this iteration, this release, this year and the next 3-5 years? What are the mechanisms we use to synchronize and retrospect for each temporal category? Without this rhythm sequence supported by planning that overlays the same time spans, progress can wander aimlessly or at least in a less than optimum undisciplined path.

My plan is to focus on the bottom-most level and move up on two different planes. The first plane is local to the team. Implementing practices that support these levels of awareness within the team, then inspecting, adapting and refining will allow me to build a platform of experience that can be fanned out across the organization. My goal is to move the organization away from reactionary fire-fighting as much as possible and encourage a further refinement of sync and plan that energizes and increases urgency.

The second plane of bottom to top movement is within the temporal domains listed above. We already use daily status reports to communicate what was accomplished yesterday, what we expect to accomplish today, and what obstacles or concerns may exist. We sync up at least once a week to roll up the daily communication into a weekly assessment of progress. With our first sprint, we are beginning to add the iteration level. Releases, roadmap and strategic levels are less well defined at this point. My plan is to move bottom-up, mastering the iteration (sprint) first, then attacking rhythm and predictability at the other higher levels.

So far, the iteration rhythm seems to be the following:

• Team scoping and commitment the morning of the first day of the iteration
• Team scope adjustment the morning of the second day of the iteration
• Daily ongoing individual status reports (email)
• End of week checkpoint to gauge progress and concerns with iteration progress
• Middle of the second week checkpoint to gauge confidence level of iteration progress
• Morning of the last day of the iteration - 15 minute standup to sync on what must get done that day to meet the iteration commitments
• End of day demo of accepted features for the iteration and pushing of incomplete work into the following iteration

Most of the meetings listed here are 15-30 minutes. The team scoping and demo meeting are more in the range of 45 minutes to 2 hours depending on the content. An alteration of this schedule might be to move to more traditional daily 15 minute "scrums" that might replace one or more of the other short meetings.

If we can master this rhythm, something like this might be scalable across the organization. Most of the time the organization tends to move at a more lumbering rhythm. Much has been written about the benefits of scaling Agile across the entire organization. Pulling decisions and actions forward and executing on a specific number of small tasks that are framed within larger goals is the motivation for adopting Agile principles across a larger scope of functional groups within the company.

Raising the Urgency Level

I just started using Agile methods in my job of running a software development team. We started our first sprint (iteration) Monday. We are not "both feet in" and only a few days have elapsed, but I already see a difference in the team's sense of urgency and energy level. We are using Rally, an Agile project management tool, to help us run the project. Our first iteration size is 2 weeks. The team was already a reasonably high-productivity team since, in general, everyone on the team is committed to getting things done the right way. What was missing was a little more structure and focus.

We met Monday morning to agree on the list of Stories (collections of tasks) for the iteration and make general estimates of the size of each. By the end of the day most team members had broken down the stories into multiple tasks with concrete estimates in hours for each one. Rally rolls up all hours estimated in tasks into the Story level and provides various views including full iteration and team member allocation. We met the next morning to make any adjustments, agree that the amount of work to accomplish in the 2 weeks seems to fit and clarify any other concepts that were fuzzy.

The team is new to Agile thinking for the most part. As manager of the team I mostly cover the role of ScrumMaster (to use a Scrum term). Scrum is a specific methodology of Agile. When I say that we are not "all in" I mean that we do not do everything recommended in the Agile literature. For example, we use email for daily status instead of daily face-to-face standups. This was a practice already in place when I arrived on the scene late last year. It seems to work well, and we have tweaked it a bit and critiqued it recently to try to make it better.

I subscribe to the method of gradually going Agile. I believe that if you have a team that is already flexible and productive, moving to Agile is a natural evolution. Not being burdened with a heavy Waterfall culture is a real benefit. A small-company environment where there is already fundamental trust and a little bit of development anarchy is much more of a blank slate in which to imprint a particular process, and Agile methods are a natural step.

There is a lot of information that preaches that Agile will fail unless undertaken under the watchful care of expert consultants and training programs. A lot of this information is produced by companies who make their living creating Agile development tools. I am not heeding that advice, and instead trusting that I know what I am doing from reading and leveraging over 25 years of experience developing and managing software teams in a variety of business circumstances and processes.

I may continue to post as the experience unfolds to record the pros, cons and results of this experiment.