A Simple Look of Lean and Agile

Somebody asked me if I were to talk about the relationship between Lean, Scrum and XP what would that be in the "simplest way possible" (At our organization, we are implementing all three). Here's how I answered:

Lean introduces the principles, or the "why's" of producing software. Focus is on maximizing customer value while minimizing waste to provide the most optimal ROI.

Scrum takes those principles and introduces the management practices, or the "when's" of producing software. Focus is on incremental delivery of working solutions that improve over time.

XP takes Lean principles and Scrum practices and introduces the technical skills, or the "how's" of producing software. Focus is on constant improvement of skills (and the underlying infrastructure) through analysis, design, and implementation of producing software.

It is my strong feeling that you really need all three to maximize your effectiveness in the development of software. Individually, each part can be implemented on it's own but you will discover something missing. Together, these really cover all aspects of developing a successful software solution.

Exploring what makes Scrum successful

Alan Shalloway from the Net Objectives Thoughts blog is digging a little deeper into the "soul" of Scrum to truly understand why Scrum works in his post "Challenging why (not if) Scrum works". Please read his post in more detail, but here is some reasons he came up with:

I have repeatedly heard that “Scrum succeeds largely because the people doing the work define how to do the work” (see From The Top by Ken Schwaber for his full text). However, I do not think that is even a third of why Scrum works - and be clear, I am certainly not questioning that Scrum works - I just want to get at the why it works.

OK, so why does Scrum work? Remember, I am not challenging that it does, just asking why. I would say Scrum works for the following reasons:

* the iterative nature of Scrum development (including the re-assessment of priorities between iterations)
* the workcell nature of the Scrum team (everyone who needs to work together is together)
* the fact that many Scrum teams are given the chance to co-locate
* that most Scrum teams work on one project at a time
* that many old, cumbersome checkpoints/forms/status reports that used to be required are abandoned because the team is doing something new
* a focus on defining acceptance tests concurrent with requirements
* the availability of a product champion (product owner to Scrum enthusiasts)

I think this is a really good list, I would also add a couple of items to it:

* frequent communication of status and removing of impediments through the Daily Standups
* continue emphasis on feedback and improvement through sprint reviews
* the team nature of the Scrum team (everybody on the team should understand and commit to the sprint through sprint planning)

For those that are using Scrum, you are well familiar with these benefits. For those that have not moved to Agile or they are having problems with their practices, consider looking at Scrum to gain these benefits. Scrum by no means is a "silver bullet", but it has already proven to be very successful where it has been implemented.

The Case for Story Point Estimates

I have been a fan of story points ever since I attended a seminar several years ago where Mike Cohn presented the concept. I never really trusted other estimating practices such as function points and time-based estimates. Why? Software development projects are rarely similar from project to project, yet these practices focused entirely on past experience. Therefore, to get a "reliable" estimate of time for every new project you needed to gain a lot of experience. In other words, you have to figure out up-front how you will do the work. Not only does this take a lot of investment up front, it also does not account that the work you do later could change based on the work you do now. The estimates assume that nothing will change in the effort of doing the work, which is definitely not true in the Agile world. What I like about Story points is the focus is on the relative size of "things", then how they will be accomplished. As Mike would say, "Estimate size now, derive duration later".

Even though I am sold on story points, I have had much difficulty selling the concept and value to others. I'm having an easier time with the development team, but really struggling with stakeholders/product owners. These groups always want to know when things will get done as soon as possible. Story points in itself don't give you the answer, however they help determine velocity of the team which eventually will help you better predict what could be part of a release. For various reasons, it is too much of a paradigm shift for some to accept an estimate that isn't time based, yet they have much comfort of the team throws out some arbitrary number early on a release without much knowledge of how events are going to unfold.

It looks like I'm not the only one dealing with this struggle. Tobias Meyer, on his blog Agile Thoughts, addresses some of the arguments others have had about using Story Points as estimates. Following are the arguments, read more on his post "Estimation: Time or Size" on how he address each arguments. Good stuff!

Argument 1: Estimating in hours allows a developer to measure his estimate against his actual, and use that data to improve his estimates in future.

Argument 2: Our customers/product owners don’t understand story points; they need to know how many hours developers are working so they know how much the work will cost.

Argument 3: Story Points will map to time anyway, very soon we’ll see that (e.g.) one story point is worth 2.5 hours, so it is better to skip the intermediate step and just measure in hours.

Argument 4: Story Points don’t allow you to improve your estimation techniques.

Video: Agile Testing

Here is another great video. This time, the topic is Agile Testing. I met the speaker, Elisabeth Hendrickson, a few months ago at Agile Open Northwest here in Portland. She led a couple of sessions, and they were some of the best attended and interesting ones of the bunch. This lady has ENERGY and a PASSION (BIG CAPS HERE) about testing. Before meeting her, I didn't know somebody could care so much about testing software. This video is from December 2006, but is still very relevant. If you are transitioning to Agile and have been used to having a separate testing group, this video is for you. If you are still struggling with how testing should be done on an Agile project, you will get something of value. Elisabeth does a great job helping understand the shift that needs to take place to do testing differently within the context of Agile. Here is the video:

Video: Agile Estimating and Planning

I guess this week is the week of video postings, as I have discovered some more great ones to share with you. Today's is from Mike Cohn. I went to a seminar a couple of years ago on the same topic and presenter as this video. There is great content here, especially if your team is struggling with estimating and don't know about story points and planning poker concepts. Mike's presentation style is also engaging and entertaining. This presentation is is two parts, click the videos below to watch each part.

Part One



Part Two

The Agile Team's Dashboard

Last summer, I shopped for a new car. I decided with rising gas prices to purchase a Hybrid. My goal in buying this car was to improve my miles per gallon (MPG) so I didn't have to spend as much as often at the pump. With this car, I have two gauges that I didn't have before. The first is next to my speedometer and shows me my MPG consumption (or electric if no gas is being used). The other gauge will show me the Tank average for MPG.

At first, I wasn't used to these measures and didn't pay much attention to them. Therefore, my driving habits were similar to what I had done before with my other car. I drove the car as I had driven the previous one. As I got familiar with my car, I started to explore both of these gauges. I started experimenting with how to increase my MPG usage. I discovered that if I accelerated a little slower after being stopped it made a difference. I discovered that I could coast more often when going downhill instead of hitting the gas and still maintain the same speed (but save on MPG usage). As I result, I started to see the MPG increase.

Then, I decided to not pay attention to either gauge for awhile. Just try to drive the car using what I have learned and see if I got the same results. Though I did better than when I first started using the car, I still was getting lower MPG by not paying attention to these gauges. These gauges were a good visual tool to help me accomplish my goal of higher MPG, and were a good reminder when my bad habits would come back and cause my MPG to drop.

So, why all of this talk about cars? Well, think about Agile teams. Their goal is develop as much working (deliverable, quality, meets customer needs) software as possible in set increments of time. How do they measure this? There are two gauges that most Agile teams use to ensure they focus on the goal of delivering working software.

First, the team calculates their velocity from Iteration to Iteration. Velocity measures the total amount of work that was accomplished to deliver working, completed stories by the end of the iteration. If a story is partially completed, the team does not get credit until the iteration in which the story has been completed. This encourages teams to focus on completing stories than completed tasks leaving incomplete stories. If the team is focusing on the completion of stories, as is a dedicated team of individuals, you should be able to sustain a certain range of velocity from iteration to iteration. Where Velocity gets lower, you should see why things are getting done. Where Velocity is higher, you need to see why the team was able to accomplish more. If the team pays attention to Velocity, they will begin to see better development practices (much like my driving habits improved after paying attention to MPG).

Second, the team uses a chart to track progress at both a Release and Iteration Level. The burndown chart shows how work in being completed on a "trip" by "trip" basis. At a Release Level, the chart shows how each Iteration is progressing and the team can get a good idea of what amount of scope is possible based on this information. At an Iteration Level, the chart takes the daily remaining hours for the team to be used in the Daily Standup to see progress. If the chart isn't going down as quickly as expected, this is an indication that the team has impediments that must be addressed. These impediments could be thrashing (team isn't getting to a resolution), dependencies to other stories/tasks (team needs to remove dependencies where they can), additional scope (additional stories and/or tasks have been determined necessary to get complete). In any of these cases, the team can quickly see the impediments impact to the iteration and make adjustments.

Both Velocity and Burndown charts are good gauges to ensure that you are doing what you can to deliver working software. These measures should expose you to some problems (waste in Lean thinking) that need to be resolved. Most of the time this requires a change in how you do things in order to accomplish the goal better. If Agile teams aren't using these gauges, much like my driving, they can get back into bad habits and find themselves not having great results after each Iteration.

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.

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.

The Agile Zealot's Handbook

Simon Baker from Agile in Action has updated his Zealot's Handbook. Here's what it says:

VALUE
IF you don't repeatedly release software
into a production environment
at least once every month
that realizes business value
for a real customer...

QUALITY
IF you're not paying constant attention to technical excellence
with simple, effective, incremental design
driven by continuous, repeatable automated testing
with at least 95% coverage...

LEARNING
IF you're not learning
by inspecting and reflecting every iteration
and you're not re-planning, adapting and improving
all of the time based on what you've learned...

TEAM
IF your team is not empowered to self-organize and be creative,
does not sit together and engage in face-to-face communication,
does not include your customer
and all the necessary skills to make its own decisions and take immediate action...

THEN YOU HAVE COMPROMISED YOUR AGILITY

Very nice! Short and sweet and incorporates all part of Agile. Thanks for the update Simon!

A good resource on code reviews

Code reviews are an essential part of ensuring that quality is properly built-in to the product development. However, for many it's been difficult to figure out how to make them effective without weighing down the team with more meetings, process and time it takes to prepare and conduct reviews. Especially, in a Lean and Agile product development environment.

Brad Appleton from his ACME blog has a good post today of a resource with lots of good information on this topic. Plus, if you act now you will get a book sent to you entirely free (shipping/handling included)!

Go to the Source

In Lean, a key practice is one called "Go to the Gemba". Here's a brief description according to Wikipedia:

Gemba is a Japanese term meaning "the place where the truth can be found." Others may call it "the value proposition."

A Gemba visit is often simply called a customer visit. The hallmarks that make it uniquely useful are:
1) The purpose is firstly to observe, occasionally to question, rarely to guide or direct.
2) The visit occurs in the context where the product or service is used, which allows direct observation of problems that arise, workarounds that are applied, and capabilities or services that are never used.
3) Sometimes the customer (or client or user) is asked to describe what he is doing while he is doing it; this provides insight into the thought processes, which often reveal differences between the customer's mental model and the model of the developers or providers of the product or service.
4) The customer will often express wishes or needs while working in context that would be forgotten or suppressed in a different context such as a structured interview or sales meeting.

Common cases for a customer visit include:
1) Enhancing the features or usability of products (especially software) or devices (especially ones aimed at very broad or very niche consumers).
2) Improving processes or tools.

I think this describes the primary use of this practice, but I can see other uses as well. Here are some other sources that should be considered as a manager:

Individual Worker - Look at each person. Do they have a significant role? Do they understand their role? Have they developed the right skills for the role? As a manager, it is your job to ensure that each person understands their purpose in the organization. It is also your job to encourage that person to continually improve how they do their work as well as increase their value to the organization. Management should make sure that the culture is such that each individual once they understand their role, have autonomy to improve it as they see fit.

Development Team - How is the team functioning? Are the processes and tools supporting the team or getting in the way? Are they communicating well? Working well together? It is crucial that the team are working in a way that work flows smoothly, there is little or no waste and everything the team does goes towards providing value to the customer.

Management - Does your management style support Lean? Do you understand what Lean is all about? Are you establishing a culture that compliments Lean? Are you a champion of Lean? Are you helping others understand it? As a manager, you need to be the experts of Lean and do all you can to understand what it takes for an organization to become Lean. If things are falling apart because people don't understand what they are doing or have gone back to their old ways, it is up to managers to educate and instill the self-discipline each person needs to have to make it successful.

This is an area that we are still struggling with but realize that it is critical to our success moving towards a Lean organization. We must "Go to the Gemba" and find the problems (and solutions) where the root source is to properly address. Otherwise, we are making a lot of assumptions that may not prove accurate. As the old saying goes, "When you assume, you make an ass out of you and me." It's important to base decisions on real facts than assumptions. Going to the source will get you to the right place to identify the facts. It's then up to you to figure our fact from fiction.

The Prime Directive of Retrospectives

Retrospectives are a core element of both Agile and Lean. The need for constant improvement through feedback throughout development is essential for success. I found out that there is now a Prime Directive for Retrospectives and I really like what is said:

Holding a retrospective ritual is a very old idea. It has served the human species well, as the stories of hunts are retold around campfires and the stories of child rearing are shared as baskets are woven. It has survived this long because it works. It’s a fundamental vehicle to discover, share, and pass along the learning from experience—something we also call “wisdom.”

I have one question: Is your organization good at acquiring and using its wisdom in creating software?

Maybe it’s time to try a retrospective. It’s something that every true learning organization has as part of its culture, and it’s one of the best ways to grow—project by project—into a smarter and increasingly successful organization.

One of the most obvious fears people have when first trying a retrospective is that the ritual will become a negative gripe session, interspersed with blame and counter blame. Clearly such an event will not contribute to much learning.

The key to a constructive successful ritual is assuring that all the participants adhere to the Retrospective Prime Directive.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgment used to embarrass.

While there are many possible interesting questions to address during a retrospective, I have found four to be key to focusing a community on learning and improvement.
1) What did we do well, that if we don’t discuss we might forget?
2) What did we learn?
3) What should we do differently next time?
4) What still puzzles us?

While this can apply directly to those using Agile and Lean practices, what's great is that you can apply this technique to any form of feedback. Ask yourself these questions on tasks you perform. Ask these with your teams. Ask these with your family. All of these areas can help these relationships through communication, learning and improvement.

Values, Principles and Practices

When I was creating this blog, I wanted to make sure I had a tag line that accurately reflected what the focus and goals of this blog were to be. Here's what I came up with:

A manager's quest to improve his organization through Lean and Agile development values, principles and practices.


Technoetic had a post awhile back that I found to be a great representation of the overall goals - values, principles and practices. While some use these terms somewhat interchangably, I truly believed that each of them represented a particular piece of the whole. The author of this post apparently agreed with me and came up with perfect definitions of each of the parts. Here they are:

Values - A description of preference between alternatives. Often the alternatives represent candidate courses of action and the value guides the selection among the alternatives. Sometimes values are basically axioms. They can be irrational in the sense that we might not be able to explain them intellectually or they might be primarily based on emotions.

Principles - Statements describing a model. A scientific principle is a statement describing an aspect of physical reality. Principles might also describe a model of social activity, for example. Principles can be fundamental or logically derived from fundamental principles. It’s commonly believed that principles are derived from values, but sometimes people have certain values because of specific principles. For example, the “value” of communication can be derived from the principle that communication improves cooperation and coordination effectiveness. This circularity between values and principles can be confusing at times.

Practices - A pattern of activity that can be repeated to achieve goals within a context. A person defining a practice is applying principles within a framework of their values (preferences). A related collection of practices might be called a process or methodology.

To make it even simpler, I could summarize the difference between these as:

Values are the feelings of what the right things are for us to do.

Principles are the guidelines of how we are to demonstrate those values.

Practices are the actions of what we do to support those principles.

As I write future posts, I will refer to these terms frequently to describe the parts of both Lean and Agile. Before I went there, I thought it would be good for us to have the same context going forward.