Thinking inside the Agile Box

Pretend you are taking a week long trip with a friend. You start packing and end up with a couple of large suitcases. Your friend arrives with one medium suitcase. You start thinking, "What are they thinking? They don't have enough clothes to last the week." You arrive to your destination. When you start unpacking, your friend's clothes are all nicely folded and no wrinkles. Your clothes look like a mess and will need to be ironed. Your friend is able to put things into drawers quickly as well as the bathroom items. You have to go through your bag and it takes you longer to find things and put them in their place. However, your friend has less clothes than you. As the week progresses, you begin to see that your friend has found ways to reuse what they wear - different shirts with the same pants - yet still appear like they aren't worn. You on the other hand, find that at the end of the trip you had clothes that you didn't wear, but had to carry around. Now you start thinking, "My friend has a better way. I've got to learn from them for the next trip!"

Was the friend always this organized? Probably not, they probably learned by somebody else. Experienced travelers have tricks on how to properly fold clothes and how to maximize every spaces in a suitcase. They have also learned what's "good enough" and not to take more than they need. Even if they end up needing fresh clothes, they will end up using a local cleaners or wash their own clothes instead of taking too much. They have learned how to best put clothes and other accessories together to maximize their use.

As my development staff is asked to reduce cycle times through iterative development using Agile best practices, their initial reaction is "That sounds all good, but we have found things to take weeks or months and that won't work with this approach." They are correct, it won't. But, just because you have done things a certain way doesn't mean that it is the ONLY way to do things. We have learned how to do things as individuals. We will now need to do those things together as a team. We have learned that each person plays a particular role and has their own specialization. We will now need to remove those specializations and have people wear multiple hats. We have learned to think about everything up front is much detail. We will now need to learn to do just enough for now and think about details when it is appropriate later. We have learned to break the work and requirements down just enough to make sense for a 6-8 month project, we will now need to refine that work to make sense for 2-4 week iterations. We have learned a way to deliver software after 8 months, we need a way to deliver that same software in a portion of that time and possibly in weeks instead of months. We need systems that get tested and built at least every day if not several times a day, the systems we have used cannot handle that load.

What's great about Agile is that it isn't just "theory" anymore, people have found it to work and improve the flexibility and responsiveness of the team to provide working solutions to customers. We can tap into these "experienced travelers" and figure out how they have done it a different and better way. It just seems strange to us because we have learned how to do things differently, not necessarily better. However, if you think that Agile is just about doing things faster you will miss the point. Agile is about doing things differently in order to deliver working software more effectively. That means we need to relearn how to build, maintain and support software under this new way. Relearn skills, tools, knowledge, processes and essentially how you do your jobs differently.

You might have thought you were a great traveler and packed accordingly, until you realized that there is a better way. However, you can't just copy the better way like it was out of a cookbook. You must understand why this experienced traveler didn't to make the change. Then, you must understand how he made the change work for them. Then, you must make the changes work for yourself. Same with Agile, you don't just adopt a methodology and away you go. You must understand the principles behind it, then determine what set of best practices fit your organization. When people ask us if we are using XP or Scrum, I respond with "Yes". "Which one?", they ask. "Both" I respond. There are practices within each that we have adopted to support Agile principles. There are other practices that we have come up with that perhaps nobody else is using. That's ok, as long as we are staying true to the goals of Agile development. I will say that it has required EVERY person to think about their jobs differently. In some cases, much differently. In the end, it required each person to "think inside a different box". An Agile Box!

Where does QA fit within Agile?

Like many development shops that have been around doing Traditional Waterfall development over the years, we have a separate department called Quality Assurance. This team consisted of non-developer types that focused primarily with ensuring quality of the product through testing activities. In our case, because we have legacy products that have been developed in technologies that don't lend itself well toward test automation, these testing activities were largely done manually. Unlike the unit-level testing that was done by the developers, the QA team primarily focused on overall system testing. This included test verification of current requirements but also a fair amount of regression testing (again manually done) to ensure that
past functionality continued to work.

As with Waterfall development, QA was largely involved late in the process. Once developers felt their code was completed, they would "throw in over the wall" to QA for testing. QA would do their initial testing, and submit bugs for things not working. Until the overall product was stable enough to give to our customers (through several release cycles), it would go through several fix/build cycles. How long this would go was highly unpredictable, and therefore would cause much frustration if our initial test estimates were too far off.

A couple of years ago, I attended the local Northwest Software Quality Conference here in Portland, Oregon. This is an excellent conference and while anybody in the software industry can get something useful out of it, the primary audience are people involved in QA. As Agile started to heat up in the software industry, presentations started to show up in every conference. Given this audience however, very few had even heard much of Agile and for those that did, weren't using Agile practices. Why? Because Agile assumed (at least at that time) that the testing role and other QA activities were just another hat that developers wore. So for those that had heard of Agile, they were resistant because they feared their jobs in the long run.

I was seeing that same reaction from my own QA group, and was dealing with how to best transition that group into a valuable role of an Agile team. After many sessions with both developers and QA, I started to see the light of how QA could fill some holes that the teams were having. So, here's how QA will look in our organization:

1) QA integrated into every team - Each member of the QA team is now co-located with the Development instead of being in a separate department.

2) QA plays Testing Manager role - QA is responsible for helping the team identify how we know when a story or task is "done". They define done by developing tests with the team that ANYBODY can run including the QA person. They also determine how best to implement that test (manual or automated, which tools, etc.)

3) QA plays Process Improvement Manager role - QA is now going to lead retrospectives at the end of iterations and releases with the team. They will ensure that there is just enough process for the team to ensure quality but not too much that the team doesn't see value in the process. They are also to ensure that all action items from the retrospective get reflected in the work in future iterations and releases.

With these three implementations, we hope to build more quality into the entire process and ensure quality earlier and often in the process. While anybody can wear the Tester hat, now QA has a much broader role in ensuring quality beyond just testing.

The Top 5: Feb - April 2007

Here are the top 5 posts most visited from February 5th through April 24th:

#1: What does it mean to be Lean? - Lean is a paradigm shift from normal thinking. Learn what it takes to think in Lean terms.

#2: An Introduction - Just some background of why I created this site and who I am.

#3: The Predictability Paradox - A link to a wonderful white paper written by Mary Poppendieck discussing predictability in software projects.

#4: An Agile Approach to adopting Agile - Some advocate taking the big bang approach to adopting Agile. Not me! If Agile is all about incremental and evolutionary delivery, why can't your adoption be the same way?

#5: Deming Revisited - I tackled Deming awhile ago from a management perspective, now I update Deming's list of Fourteen Points from an Agile and Lean perspective.

Growing Your Leaders

Alan Shalloway from the Net Objectives Thoughts blog challenges how Agile has viewed management and leadership up to this point in his post "The Need for Leadership in Scrum". Here are some highlights:

There underscores the notion that self-managing teams and direction from the top are somehow opposed to each other. In practice, this may be. But that is because in practice, leadership is missing. Direction in the form of command and control is bad. Direction in the form of vision and matching people to their abilities is not. This points to one deficiency I have seen in the general Agile community, and one that, I believe, is a serious impediment to having the Agile community have success at the enterprise level. I am referring to the fact that most Agilists do not trust management to do what is right – they feel the team must be protected from management. I have heard this opinion voiced in several books and from several leading agile consultants/practitioners – and I disagree with it.

Unfortunately, this attitude has been pervasive from the beginning of the Agile community. Given the heavy focus on over-bearing process that has gripped this industry for years, this is not surprising. However, it is time to include leadership and management in the transition to agile methods. We must see how we can marry respect for people (and hence the team) along with process. This requires leadership and proper management.

Buckingham, in his excellent book, The One Thing You Should Know describes leadership as the “ability to create a solid vision of a better future for those people he/she is leading. ” A leader must have a compelling desire to move towards that vision. Buckingham defines management as the “ability to match people’s tasks with their skills. ” A good manager is liked a skilled Chess Master. As opposed to checkers, where all the pieces (until one gets kinged) are the same, in chess, different pieces have different strengths. A good chess player knows how to use these strengths. A good manager knows how to maximize the strengths of his staff. Hence, leadership and management are not opposed to each other – they just have different functions.

Keeping Buckingham’s views in mind, the role of leadership and management then is to create the vision for the Scrum teams to be effective and to staff the teams with the appropriate resources. But just creating the vision is not enough. Leadership and management must help create the structure within which the team works to assist the team. This is something Scrum teams cannot do on their own. Ignoring this issue is what often has Scrum teams feel they must protect themselves from the organization when what they need to do is help the organization see how to better support the team.

If Scrum can’t help us here, what can? This is where Lean Thinking comes in. In a nutshell, Lean Thinking tells us to set things up so we can have fast-flexible-flow. That is, we can get customer requests in and get business value out – quickly and repeatedly. At Net Objectives we base our entire software development philosophy on this (which is why we call it SPeeD: Sustainable Product Development). The issue is – “how can I develop software quickly now (to deliver business value quickly) while retaining the ability to add business value quickly in the future.”

Read more in Alan's post.

In the book The Toyota Way by Jeffery Liker, one of the 14 principles outlined says "Grow Leaders Who Throughly Understand the Work, Live the Philosophy, and Teach It to Others". At the beginning of the chapter, there's an excellent quote that parallels Alan's frustration mentioned above:

Until senior management gets their egos out of the way and goes to the whole team and leads them all together...senior management will continue to miss out on the brain power and extraordinary capabilities of all their employees. At Toyota, we simple place the highest value on our team members and do the best we can to listen to them and incorporate their ideas into our planning process. -- Alex Warren, former Senior VP, Toyota Motor Manufacturing, Kentucky.

In summarizing this principle, Liker says:

If we look at all of the great leaders in Toyota's history we see they share several common traits:
1) Focused on a long-term purpose for Toyota as a value-added contributor to society.
2) Never deviated from the precepts of the Toyota Way DNA and lived and modeled themselves around this for all to see.
3) Worked their way up doing the detailed work and continued to go to the gemba - the actual place where the real added-value work is done.
4) Saw problems as opportunities to train and coach their people.

This doesn't sound like the ol' command and control type of manager works in this paradigm does it? However, managers are needed to provide Agile teams this kind of guidance. To do so, managers must respect team members as well as the other way around. Each have their place and need to understand their interdependencies in order to be a successful organization.

Now, Rules for Self-Leadership

A few posts ago, I talked about a great post by Rosa Say around self-management. Now, she has followed this up with a separate list this time focused on leadership qualities. I agree with Rosa that there is a difference between management and leadership qualities and that everybody should strive to accomplish both. Here, Rosa elaborates on this as well as presents the 12 Rules of Self-Leadership. Enjoy!

Management and Leadership are not interchangeable words for me. We need both of them, for in part, management tends to be more internally focused (within a company, within an industry, within a person) whereas leadership is more externally focused on the future-forward actions you will take in the greater context of industry, community, or society. They have commonality to be sure, for instance, both are about capitalizing on human capacity, however they are defined by the differences we value in them: Management tends to be about systems and processes, whereas Leadership is more about ideas and experiments.

I believe there is both art and discipline in each, and I think of these rules as the discipline which helps reveal the great capacity of the art. Thus last time, twelve suggestions to help you self-manage, with a more disciplined you newly able to reveal your art. Now, twelve to help you self-lead, so a more disciplined you is newly able to reveal the art in others, those who choose you to lead them.

12 Rules for Self-Leadership

1. Set goals for your life; not just for your job. What we think of as “meaning of life” goals affect your lifestyle outside of work too, and you get whole-life context, not just work-life, each feeding off the other.
2. Practice discretion constantly, and lead with the example of how your own good behavior does get great results. Otherwise, why should anyone follow you when you lead?
3. Take initiative. Volunteer to be first. Be daring, bold, brave and fearless, willing to fall down, fail, and get up again for another round. Starting with vulnerability has this amazing way of making us stronger when all is done.
4. Be humble and give away the credit. Going before others is only part of leading; you have to go with them too. Therefore, they’ve got to want you around!
5. Learn to love ideas and experiments. Turn them into pilot programs that preface impulsive decisions. Everything was impossible until the first person did it.
6. Live in wonder. Wonder why, and prize “Why not?” as your favorite question. Be insatiably curious, and question everything.
7. There are some things you don’t take liberty with no matter how innovative you are when you lead. For instance, to have integrity means to tell the truth. To be ethical is to do the right thing. These are not fuzzy concepts.
8. Believe that beauty exists in everything and in everyone, and then go about finding it. You’ll be amazed how little you have to invent and much is waiting to be displayed.
9. Actively reject pessimism and be an optimist. Say you have zero tolerance for negativity and self-fulfilling prophecies of doubt, and mean it.
10. Champion change. As the saying goes, those who do what they’ve always done, will get what they’ve always gotten. The only things they do get more of are apathy, complacency, and boredom.
11. Be a lifelong learner, and be a fanatic about it. Surround yourself with mentors and people smarter than you. Seek to be continually inspired by something, learning what your triggers are.
12. Care for and about people. Compassion and empathy become you, and keep you ever-connected to your humanity. People will choose you to lead them.

Read more in her post!

One Story Flow

One of the practices in Lean is this idea of One Piece Flow. What does this mean exactly? It focuses on getting more components completed more quickly by focusing on the completion of each one instead of having too much work in process. The thinking is that if your team can produce one component quickly with quality, you will have peak efficiency for future components.

So, where does this fit into Agile? In iteration planning, the team is working with a set of Stories. Here's where you can go in two different directions and has been a constant challenge in our organization. Where you go from here can potentially have two very different results.

First, you could ask the team who wants to work on each Story. Each individual responsible for the Story can then go off and determine the Tasks and Tests necessary to complete the Story. So, if you have a team of five developers, you will have five Stories being worked on (at a minimum, they may take on more Stories if they believe they have time in the Iteration and the Stories are small enough).

Or, you could have the entire team in Iteration Planning determine both the Tests and Tasks necessary for the first two or three Stories (more if you have a smooth process ). Then, have the team implement the first Story together (or as many team members as possible). If there isn't enough work for everyone, some go and start implementing the second Story. If the team members responsible for the first Story need help, others working on the second Story join the effort. The goal here is for the team to get each Story implemented as quickly as possible before they go on to the next Story. This is what I will coin "One Story Flow".

As I mention, we are still really struggling with this because it has been the nature of developers to have each person work on their individual piece and to bring the pieces together during some time of integration. However, this way of thinking starts to produce mini-Waterfalls within each iteration. Also, I have seen more unfinished Stories as a result. I would rather have more Stories that have been carried over to the next iteration at 0% than at 50%. I would also want more Stories that have been completed by the team at 100%.

If you are struggling with the team's performance and completion of Stories, try the "One Story Flow" approach. You will have more flexibility as a team and the team will be more in sync on how each Story has been implemented and how it contributes to the big picture of the product. More discussions up front will resolve conflicts and turn assumptions into facts. Finding ways to implement one Story after another will address issues such as specialization of skills, knowledge, and bottlenecks in the development process. These are painful but good things to discover. Because if the team can find ways to implement one Story better, they will be able to implement all Stories better!

Rules for Self-Management

If you want Agile to be more successful for your organization, you need each individual to think differently about their role and expectation from management. For the teams to be self-organizing, you need each individual to be self-managed. This isn't to say that management in an Agile organization isn't necessary, as they need to be there to provide direction and remove roadblocks for the team if the team cannot do it for themselves.

However, the more the team can manage for themselves, the greater the productivity and efficiency. After all, part of Agile is to be able to deliver working software with better quality and response time.

Rosa Say has always been one of my favorite bloggers on the top of management. She has a recent post on her Talking Story blog that as I read it realized how well it would work on an Agile team if the team adopted her 12 Rules of Self-Management. Here they are, read it for yourself and imagine if each individual followed these rules:

1. Live by your values, whatever they are. You confuse people when you don’t, because they can’t predict how you’ll behave.
2. Speak up! No one can “hear” what you’re thinking without you be willing to stand up for it. Mind-reading is something most people can’t do.
3. Honor your own good word, and keep the promises you make. If not, people eventually stop believing most of what you say, and your words will no longer work for you.
4. When you ask for more responsibility, expect to be held fully accountable. This is what seizing ownership of something is all about; it’s usually an all or nothing kind of thing, and so you’ve got to treat it that way.
5. Don’t expect people to trust you if you aren’t willing to be trustworthy for them first and foremost. Trust is an outcome of fulfilled expectations.
6. Be more productive by creating good habits and rejecting bad ones. Good habits corral your energies into a momentum-building rhythm for you; bad habits sap your energies and drain you.
7. Have a good work ethic, for it seems to be getting rare today. Curious, for those “old-fashioned” values like dependability, timeliness, professionalism and diligence are prized more than ever before. Be action-oriented. Seek to make things work. Be willing to do what it takes.
8. Be interesting. Read voraciously, and listen to learn, then teach and share everything you know. No one owes you their attention; you have to earn it and keep attracting it.
9. Be nice. Be courteous, polite and respectful. Be considerate. Manners still count for an awful lot in life, and thank goodness they do.
10. Be self-disciplined. That’s what adults are supposed to “grow up” to be.
11. Don’t be a victim or a martyr. You always have a choice, so don’t shy from it: Choose and choose without regret. Look forward and be enthusiastic.
12. Keep healthy and take care of yourself. Exercise your mind, body and spirit so you can be someone people count on, and so you can live expansively and with abundance.