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!
Monday, April 30, 2007
Wednesday, April 25, 2007
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.
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.
Tuesday, April 24, 2007
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.
#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.
Monday, April 23, 2007
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:
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:
In summarizing this principle, Liker says:
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.
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.
Thursday, April 19, 2007
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!
Read more in her post!
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!
Wednesday, April 18, 2007
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!
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!
Tuesday, April 17, 2007
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:
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.
Monday, April 16, 2007
Iteration Planning for the Unplanned
On any project, you will have both planned and unplanned tasks. Planned are those tasks that you knew ahead of time and scheduled some of your work towards those efforts. Unplanned are everything else. In many software shops including mine, the people doing the development work also help internal operations with ongoing technical support for internal and external customers.
Though Agile helps adapt to change by accommodating unplanned tasks in future iterations, there is still a challenge of what happens in the current iteration. If you are doing Scrum, it is expected that at the start of each iteration that the team commits to the scope of that iteration and that any additional work requested by customers should be considered in future iterations. Sounds good, but most technical support is needed on a much frequent basis and turnaround must be at a minimum. Therefore, you can have support issues to resolve on an hourly basis at times and you must respond within the next 12 - 24 hours. So, how do teams address these issues? Mishkin Berteig from Agile Advice has identified a few in his latest post:
We have tried both #1 and #3. The problem with #3 is that developers that are put on the support work would love to do some development work. Plus, it is often difficult to have the knowledge (at least in our organization) to have a select few people who can address all of the support issues. However, if you try and combine support issues with ongoing development, you will find yourself trying #1 next. Unfortunately, it is very difficult to estimate what percentage of time should be put towards Support vs. Development as Support issues will come and go at an expected rate.
I don't think we can manage one week iterations (idea #4) effectively at this point at least until we become more mature at Agile and have the right infrastructure in place to turnaround iterations this quickly.
This leaves us with #2, which is what we are trying to do at this point. On our current Iteration Schedule board, we will have a Story called Issues that will be at the top of the list. Then, every issue will be identified as a Task and will have a color designation to help it stand out against "Planned" tasks and stories. I like this idea because it helps the team address what is reality but also balance the priorities of the Issues against Development stories. It also makes since that the Development team OWN the support issues since they have the most knowledge and skills to address issues in their own product and technical domain.
Though Agile helps adapt to change by accommodating unplanned tasks in future iterations, there is still a challenge of what happens in the current iteration. If you are doing Scrum, it is expected that at the start of each iteration that the team commits to the scope of that iteration and that any additional work requested by customers should be considered in future iterations. Sounds good, but most technical support is needed on a much frequent basis and turnaround must be at a minimum. Therefore, you can have support issues to resolve on an hourly basis at times and you must respond within the next 12 - 24 hours. So, how do teams address these issues? Mishkin Berteig from Agile Advice has identified a few in his latest post:
1) The part-time allocation to the iteration's work is most common. There are a couple things that need to be done to make this work well in the long term. The main thing is to make the allocation of time inflexible: if you allocate 50% to the iteration and 50% to support, then you should never be flexible about that allocation. This is necessary in order for the team to make a commitment at the start of each iteration.
2) Another common method is the "fluorescent note card" method which requires stakeholder negotiation around the impact of interruptions. With this method, any time a stakeholder comes to the team with a request, the Process Facilitator writes the request on a bright colored note card. The team then does a task breakdown on the card and using their normal process (whatever that is) estimates the work. The requesting stakeholder then has to negotiate with any other stakeholders about what work to remove from the iteration in order to make room for the new work. The trick here is that the team has to be involved because they have already started on some of the work and it might be difficult to dis-entangle things enough. This process works well primarily because it makes the tradeoffs visible. It does not work so well with letting the team make their commitments.
3) A third common method is to form two separate teams: one doing new work, one doing support work. This is simple, effective, and annoying for the people on the team doing the support work! Please don't consider a rotation system since this destroys the process of team development and makes it nearly impossible for the team doing new work to learn their capacity for the purposes of commitment.
4) A less common, but fourth method is to have extremely short iterations. In this method, choose your iteration length to be so short that you can always start work on urgent interruptions before anyone gets impatient! This can be exhausting, but it is one of the best ways to get the team and the organization to understand the large toll that these interruptions take.
We have tried both #1 and #3. The problem with #3 is that developers that are put on the support work would love to do some development work. Plus, it is often difficult to have the knowledge (at least in our organization) to have a select few people who can address all of the support issues. However, if you try and combine support issues with ongoing development, you will find yourself trying #1 next. Unfortunately, it is very difficult to estimate what percentage of time should be put towards Support vs. Development as Support issues will come and go at an expected rate.
I don't think we can manage one week iterations (idea #4) effectively at this point at least until we become more mature at Agile and have the right infrastructure in place to turnaround iterations this quickly.
This leaves us with #2, which is what we are trying to do at this point. On our current Iteration Schedule board, we will have a Story called Issues that will be at the top of the list. Then, every issue will be identified as a Task and will have a color designation to help it stand out against "Planned" tasks and stories. I like this idea because it helps the team address what is reality but also balance the priorities of the Issues against Development stories. It also makes since that the Development team OWN the support issues since they have the most knowledge and skills to address issues in their own product and technical domain.
Thursday, April 12, 2007
The Ultimate Measure of Agile?
I attended a local lunch meeting where a panel of people talked about Agile development and how they addressed challenges in each of their organizations. Two of the panelists were managers in software product environments. As they talked, it was obvious that each person was at a different stage of maturity in their adoption of Agile. The first speaker seemed to think they were doing Agile development, but his description of their lifecycle seemed to indicate that they were just doing Iterative development with mini-waterfalls. The second speaker seemed to be much further along as they were committed to short, timeboxed iterations of 2 weeks with co-located teams serving both testing and development efforts.
When it came to Q&A, there was something that was bugging me so I asked them this question, "How has the adoption of Agile impacted the Release Cycle time?" The answer from both was what I expected after hearing the earlier discussion, "Not much at all". Because of marketing and other budgetary reasons, they felt they could only do a release or perhaps two a year.
And yet, especially that they are managers, I think they are missing perhaps the ultimate measure of Agile - How quickly are we giving our customers working software? Perhaps this is what I have learned from Lean and the emphasis on Waste and Value. Within Lean, the emphasis is to always improve the cycle time to the customer by providing the most valuable functions and minimizing waste. Part of waste is partially completed functionality.
I think as people implement Agile, they will realize that they need to mature to a point where they are incorporating Lean. After all, shouldn't software be about maximizing ROI from both the customer and shareholder point-of-view? You cannot improve ROI if you aren't improving the cycle time. You cannot improve cycle time without improving quality and removing waste.
While each of these individuals have gained some benefits with Agile such as better adapting to change, getting frequent feedback, and better ways to track progress, they still haven't realized the greatest reward of all - getting working software out to customers as quickly as possible. This goes beyond budgets and marketing plans, and turns the organization 180 degrees to fully accommodate customers. They don't want to have to wait a whole year for another product, they want changes as quickly as possible. If you can't find a way to make it happen, it's possible a competitor will.
Maximizing Customer and Shareholder ROI by provide working product that meets both business and customer value as quickly as possible. This is the ultimate measure of being an Agile organization!
When it came to Q&A, there was something that was bugging me so I asked them this question, "How has the adoption of Agile impacted the Release Cycle time?" The answer from both was what I expected after hearing the earlier discussion, "Not much at all". Because of marketing and other budgetary reasons, they felt they could only do a release or perhaps two a year.
And yet, especially that they are managers, I think they are missing perhaps the ultimate measure of Agile - How quickly are we giving our customers working software? Perhaps this is what I have learned from Lean and the emphasis on Waste and Value. Within Lean, the emphasis is to always improve the cycle time to the customer by providing the most valuable functions and minimizing waste. Part of waste is partially completed functionality.
I think as people implement Agile, they will realize that they need to mature to a point where they are incorporating Lean. After all, shouldn't software be about maximizing ROI from both the customer and shareholder point-of-view? You cannot improve ROI if you aren't improving the cycle time. You cannot improve cycle time without improving quality and removing waste.
While each of these individuals have gained some benefits with Agile such as better adapting to change, getting frequent feedback, and better ways to track progress, they still haven't realized the greatest reward of all - getting working software out to customers as quickly as possible. This goes beyond budgets and marketing plans, and turns the organization 180 degrees to fully accommodate customers. They don't want to have to wait a whole year for another product, they want changes as quickly as possible. If you can't find a way to make it happen, it's possible a competitor will.
Maximizing Customer and Shareholder ROI by provide working product that meets both business and customer value as quickly as possible. This is the ultimate measure of being an Agile organization!
Wednesday, April 11, 2007
The Agile Zealot's Handbook
Simon Baker from Agile in Action has updated his Zealot's Handbook. Here's what it says:
Very nice! Short and sweet and incorporates all part of Agile. Thanks for the update Simon!
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!
Monday, April 9, 2007
Deming Revisited
Note: This post originally appeared in my other blog, Random Thoughts from a CTO in February 2006. I have updated it based on what I have learned and tied it more directly to Lean development.
You can't talk about management without eventually bringing up W. Edwards Deming. Deming is a fascinating individual and his ideas have challenged the future of management. One of his contributions is fourteen key principles of management for transforming business effectiveness. As I have been learning more about Lean, I am finding that there is significant overlap between Lean principles and these by Deming. This is no coincidence, as Deming learned a lot from Japanese companies include Toyota. Here are each of the 14, with my comments following each one:
1. Create constancy of purpose for the improvement of product and service, with the aim to become competitive, stay in business, and provide jobs.
Skip: Too many times in software development, we fall victim to the "kitchen-sink mentality". The focus is on what the technology can do more than what is important for business. We lose track that we need to get something out the door that allows us to stay competitive and in business. Competition has shown us that things can get done more quickly. Customers expectations are higher than ever in wanting quick responsiveness. You must figure out what you absolutely have to produce and then get it out as quickly as possible without compromising quality. Is your company aligned around your particular products or do they have various project teams that can players every few months? Is it easy or difficult to understand why products are going because initiatives don't align well with the progression of each product?
2. Adopt a new philosophy of cooperation (win-win) in which everybody wins and put it into practice by teaching it to employees, customers and suppliers.
Skip: Partnerships, this is what we are talking about. Let's work on the solution together. Let's get rid of our own political agendas and figure out what we can make together. We need each other, so let's recognize that. We are moving more towards this model but it is slow going. There are still customers, employees and suppliers who just don't "get it" and are only looking out for number 1. I wish those people could realize how much easier life would be if you think of these relationships as cooperative instead of "give-and-take".
3. Cease dependence on mass inspection to achieve quality. Instead, improve the process and build quality into the product in the first place.
Skip: Years ago, if you did think about quality you usually had a testing group that would manually review the product before it went out the door. Then, if you took it a step further, you would have customers "test" your product in an "alpha" or "beta" release. However, organizations are finding out that it is best to be proactive instead of reactive when it comes to quality. Automate testing, create tests before design or implementation, make people think about the quality of the solution as requirements are being gathered. Those organizations that build quality in by checking early and often are going to be more successful in the long-term. Why? Because while the competitors are having to go back and fix past mistakes that could have been caught, you are able to focus on better meeting the customers' needs right now!
4. End the practice of awarding business on the basis of price tag alone. Instead, minimize total cost in the long run. Move toward a single supplier for any one item, based on a long-term relationship of loyalty and trust.
Skip: I have learned a long time ago when it comes to looking at financials and success in any business, you have to focus on the long-term results and impact of your short-term decisions. You may think your short-term decisions have merit, but if you choose to ignore (or understand) the long term negative effects you could get yourself in trouble. On the other hand, if you are focused on long-term partnerships that work for all of those concerned, you will be better off.
5. Improve constantly, and forever, the system of production, service, planning, of any activity. This will improve quality and productivity and thus constantly decrease costs.
Skip: For many organizations, this is a challenge. Why? Because they like to move on. Fix something, it works, leave it only since it works (the ol' adage, "If it's not broke, don't fix it"). So, even if it does seem to work,it may not be the most efficient or it may tend to have problems as time going on and the world changes around it. The best organizations are those that recognize that change is always happening and can adapt to those changes quickly. When they realize that there are always improvements, and the company rewards those who make improvements to improve quality or productivity or reduce costs, then you will have an efficient organization. Now, I encourage others to have the attitude of "Is there a better way?"
6. Institute training for skills.
Skip: Does your organization have formal training? Is it for new people only? Or does your organization expect the skills to be developed before they are hired? Or does your organization "train by fire". Organizations need to evaluate their training programs and look for consistency. In other words, are people being consistent in their performance based on their knowledge? Are they getting the same training? If they need refresher courses, is that available? If everyone isn't "sharpening their blades" on a regular basis you can quickly find that you aren't able to adapt to changing conditions or have as much flexibility in responding to change as you used to. The world is changing around us, don't you think each of us needs to change and improve as well? How can you do that without some time around training?
7. Adopt and institute leadership for the management of people, recognizing their different abilities, capabilities, and aspiration. The aim of leadership should be to help people, machines, and gadgets do a better job. Leadership of management is in need of overhaul, as well as leadership of production workers.
Skip: I am a firm believer that leadership isn't something you are born with, isn't part of your DNA, isn't part of a job title, and that each person is capable of becoming a leader. Some will take on more responsibilities than others, but each person need to become an expert of their own domain. You can't be an expert in my opinion if you aren't leading others with your expertise. Organizations promote people every day into management roles that they are prepared for. We should constantly encourage the building of leaders within the organization. I have told many people that one of my primary job duties is to create leaders for the organization. It is my legacy. I truly believe that!
8. Drive out fear and build trust so that everyone can work more effectively.
Skip: Mutual trust and respect are the heart and soul of a team's productivity. If you don't have one or both towards a teammate, you will find extra work is produced to work around this. Extra work means less productivity...period. Also, you also need to be able to take risks and make decisions that could have a negative impact. Of course, you should do your homework if the risk occurs. On the other hand, you can't be scared of making decisions by always going the safe route.
9. Break down barriers between departments. Abolish competition and build a win-win system of cooperation within the organization. People in research, design, sales, and production must work as a team to foresee problems of production and use that might be encountered with the product or service.
Skip: I have seen this happen in both large companies I have worked for as well as smaller ones. Why does this happen? Easy....departments have different goals that are in conflict with each other. Processes or work doesn't seem to flow well between departments, or work seems to contradict each other. This causes much frustration and the feeling of "us" vs. "them". I have even seen organizations with there are contests between different development groups to see who is better. While this may sound like healthy competition, it often creates "classes" of groups within the organization that is anything but healthy. The entire organization should look at the processes across the organization and determine if everyone is working towards customer needs in the most efficient way possible. We can't forget that the "us" is the entire organization and the "them" is our customers, vendors and even competitors. We can't forget to serve customers, support vendors and go after the external competitors for market share.
10. Eliminate slogans, exhortations, and targets asking for zero defects or new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
Skip: This is SO true. The cost of trying to support zero defects goes up exponentially as you get closer to zero. There are always acceptable defects that can wait on being fixed. The opposite is also true, in that there are defects that could cause data corruption that are not acceptable. You need to decide what is and is not acceptable and make sure that employees, customers and vendors are on the same page. If customers expect zero defects, and internally you know that is impossible, you will only have frustration on both sides.
11. Eliminate numerical goals, numerical quotas and management by objectives. Substitute leadership.
Skip: I hear from people that you "can't manage what you can't measure". However, I really haven't had any particular metrics for many years....yet, I know that I have been successful with the groups that I have managed. Whenever I have tried to implement metrics...it seems the focus has been more on keeping up with the metrics than focusing on the work itself. Isn't it the work that should be more important? In the end, I'll pick a good leader that motivates people to perform over a manager that is making sure his people are conforming to the metrics any time! I'm not saying metrics are bad but that they need to measure true value and support the right goals and behaviors of the organization.
12. Remove barriers that rob people of joy in their work. This will mean abolishing the annual rating or merit system that ranks people and creates competition and conflict.
Skip: Dilbert and The Office typically portray the workplace as a terrible place to be. Though it's done in a humorous fashion, it's still a testament to how people view most organizations. Managers from all levels should pay attention to this one, as they create programs, policies, procedures, etc that seem like good ideas but cause more conflict than they resolve. Are these things going towards improving morale and productivity or against it?
13. Institute a vigorous program of education and self-improvement.
Skip: Education and self-improvement seem to take a second seat to getting the work done. They are either used as recruiting perks, or rewards for hard work. I haven't been with an organization that puts a high enough value on these activities. Most people don't realize that if the company invests in people this way, and encourages self-improvement....that will lead to organizational improvement with better skills, higher knowledge and overall desire to learn.
14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.
Skip: Imagine a company where everybody has a particular role, everybody knew what was most important or not, everybody worked towards the same goals. I haven't seen it yet, but would love to be part of an organization like that! This is the ultimate goal of a Lean and Agile organization.
You can't talk about management without eventually bringing up W. Edwards Deming. Deming is a fascinating individual and his ideas have challenged the future of management. One of his contributions is fourteen key principles of management for transforming business effectiveness. As I have been learning more about Lean, I am finding that there is significant overlap between Lean principles and these by Deming. This is no coincidence, as Deming learned a lot from Japanese companies include Toyota. Here are each of the 14, with my comments following each one:
1. Create constancy of purpose for the improvement of product and service, with the aim to become competitive, stay in business, and provide jobs.
Skip: Too many times in software development, we fall victim to the "kitchen-sink mentality". The focus is on what the technology can do more than what is important for business. We lose track that we need to get something out the door that allows us to stay competitive and in business. Competition has shown us that things can get done more quickly. Customers expectations are higher than ever in wanting quick responsiveness. You must figure out what you absolutely have to produce and then get it out as quickly as possible without compromising quality. Is your company aligned around your particular products or do they have various project teams that can players every few months? Is it easy or difficult to understand why products are going because initiatives don't align well with the progression of each product?
2. Adopt a new philosophy of cooperation (win-win) in which everybody wins and put it into practice by teaching it to employees, customers and suppliers.
Skip: Partnerships, this is what we are talking about. Let's work on the solution together. Let's get rid of our own political agendas and figure out what we can make together. We need each other, so let's recognize that. We are moving more towards this model but it is slow going. There are still customers, employees and suppliers who just don't "get it" and are only looking out for number 1. I wish those people could realize how much easier life would be if you think of these relationships as cooperative instead of "give-and-take".
3. Cease dependence on mass inspection to achieve quality. Instead, improve the process and build quality into the product in the first place.
Skip: Years ago, if you did think about quality you usually had a testing group that would manually review the product before it went out the door. Then, if you took it a step further, you would have customers "test" your product in an "alpha" or "beta" release. However, organizations are finding out that it is best to be proactive instead of reactive when it comes to quality. Automate testing, create tests before design or implementation, make people think about the quality of the solution as requirements are being gathered. Those organizations that build quality in by checking early and often are going to be more successful in the long-term. Why? Because while the competitors are having to go back and fix past mistakes that could have been caught, you are able to focus on better meeting the customers' needs right now!
4. End the practice of awarding business on the basis of price tag alone. Instead, minimize total cost in the long run. Move toward a single supplier for any one item, based on a long-term relationship of loyalty and trust.
Skip: I have learned a long time ago when it comes to looking at financials and success in any business, you have to focus on the long-term results and impact of your short-term decisions. You may think your short-term decisions have merit, but if you choose to ignore (or understand) the long term negative effects you could get yourself in trouble. On the other hand, if you are focused on long-term partnerships that work for all of those concerned, you will be better off.
5. Improve constantly, and forever, the system of production, service, planning, of any activity. This will improve quality and productivity and thus constantly decrease costs.
Skip: For many organizations, this is a challenge. Why? Because they like to move on. Fix something, it works, leave it only since it works (the ol' adage, "If it's not broke, don't fix it"). So, even if it does seem to work,it may not be the most efficient or it may tend to have problems as time going on and the world changes around it. The best organizations are those that recognize that change is always happening and can adapt to those changes quickly. When they realize that there are always improvements, and the company rewards those who make improvements to improve quality or productivity or reduce costs, then you will have an efficient organization. Now, I encourage others to have the attitude of "Is there a better way?"
6. Institute training for skills.
Skip: Does your organization have formal training? Is it for new people only? Or does your organization expect the skills to be developed before they are hired? Or does your organization "train by fire". Organizations need to evaluate their training programs and look for consistency. In other words, are people being consistent in their performance based on their knowledge? Are they getting the same training? If they need refresher courses, is that available? If everyone isn't "sharpening their blades" on a regular basis you can quickly find that you aren't able to adapt to changing conditions or have as much flexibility in responding to change as you used to. The world is changing around us, don't you think each of us needs to change and improve as well? How can you do that without some time around training?
7. Adopt and institute leadership for the management of people, recognizing their different abilities, capabilities, and aspiration. The aim of leadership should be to help people, machines, and gadgets do a better job. Leadership of management is in need of overhaul, as well as leadership of production workers.
Skip: I am a firm believer that leadership isn't something you are born with, isn't part of your DNA, isn't part of a job title, and that each person is capable of becoming a leader. Some will take on more responsibilities than others, but each person need to become an expert of their own domain. You can't be an expert in my opinion if you aren't leading others with your expertise. Organizations promote people every day into management roles that they are prepared for. We should constantly encourage the building of leaders within the organization. I have told many people that one of my primary job duties is to create leaders for the organization. It is my legacy. I truly believe that!
8. Drive out fear and build trust so that everyone can work more effectively.
Skip: Mutual trust and respect are the heart and soul of a team's productivity. If you don't have one or both towards a teammate, you will find extra work is produced to work around this. Extra work means less productivity...period. Also, you also need to be able to take risks and make decisions that could have a negative impact. Of course, you should do your homework if the risk occurs. On the other hand, you can't be scared of making decisions by always going the safe route.
9. Break down barriers between departments. Abolish competition and build a win-win system of cooperation within the organization. People in research, design, sales, and production must work as a team to foresee problems of production and use that might be encountered with the product or service.
Skip: I have seen this happen in both large companies I have worked for as well as smaller ones. Why does this happen? Easy....departments have different goals that are in conflict with each other. Processes or work doesn't seem to flow well between departments, or work seems to contradict each other. This causes much frustration and the feeling of "us" vs. "them". I have even seen organizations with there are contests between different development groups to see who is better. While this may sound like healthy competition, it often creates "classes" of groups within the organization that is anything but healthy. The entire organization should look at the processes across the organization and determine if everyone is working towards customer needs in the most efficient way possible. We can't forget that the "us" is the entire organization and the "them" is our customers, vendors and even competitors. We can't forget to serve customers, support vendors and go after the external competitors for market share.
10. Eliminate slogans, exhortations, and targets asking for zero defects or new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
Skip: This is SO true. The cost of trying to support zero defects goes up exponentially as you get closer to zero. There are always acceptable defects that can wait on being fixed. The opposite is also true, in that there are defects that could cause data corruption that are not acceptable. You need to decide what is and is not acceptable and make sure that employees, customers and vendors are on the same page. If customers expect zero defects, and internally you know that is impossible, you will only have frustration on both sides.
11. Eliminate numerical goals, numerical quotas and management by objectives. Substitute leadership.
Skip: I hear from people that you "can't manage what you can't measure". However, I really haven't had any particular metrics for many years....yet, I know that I have been successful with the groups that I have managed. Whenever I have tried to implement metrics...it seems the focus has been more on keeping up with the metrics than focusing on the work itself. Isn't it the work that should be more important? In the end, I'll pick a good leader that motivates people to perform over a manager that is making sure his people are conforming to the metrics any time! I'm not saying metrics are bad but that they need to measure true value and support the right goals and behaviors of the organization.
12. Remove barriers that rob people of joy in their work. This will mean abolishing the annual rating or merit system that ranks people and creates competition and conflict.
Skip: Dilbert and The Office typically portray the workplace as a terrible place to be. Though it's done in a humorous fashion, it's still a testament to how people view most organizations. Managers from all levels should pay attention to this one, as they create programs, policies, procedures, etc that seem like good ideas but cause more conflict than they resolve. Are these things going towards improving morale and productivity or against it?
13. Institute a vigorous program of education and self-improvement.
Skip: Education and self-improvement seem to take a second seat to getting the work done. They are either used as recruiting perks, or rewards for hard work. I haven't been with an organization that puts a high enough value on these activities. Most people don't realize that if the company invests in people this way, and encourages self-improvement....that will lead to organizational improvement with better skills, higher knowledge and overall desire to learn.
14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.
Skip: Imagine a company where everybody has a particular role, everybody knew what was most important or not, everybody worked towards the same goals. I haven't seen it yet, but would love to be part of an organization like that! This is the ultimate goal of a Lean and Agile organization.
Friday, April 6, 2007
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)!
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)!
Thursday, April 5, 2007
Can you really plan for the long-term future?
I attended a "planning conference" last night as part of my involvement in Cub Scouts with my son. The purpose of this meeting according to the leader was to "knock out the schedule" through summer of 2008 and we had the next 4 hours to do so. Initially, as we focused on the next few months things went pretty well. However, things begin to break down quickly the further out we went. One of the primary reasons is that the next scouting year would begin in the Fall of 2007 and that will cause some changes with kids, parents and leaders in that process. Therefore, it was difficult to firm up dates because the people involved by that time will be different. Yet, we were told by the leader to just give it our best shot and go on. The other reason that became frustrating is that the leader wanted particular dates and times that we would have different events. It was easy for the group to determine particular months, but much harder to nail down days and almost impossible to determine times. Why? Because who knows their own schedules a year from now (much less the next month). In the end, we created our "project plan" of activities but it left everybody a little frustrated, very tired, and most everybody skeptical that the plan would reflect reality a year from now.
I don't place blame on the leader of this because she was doing what had been done before. It was my first time, and knowing the problems I have had in the past with long term software project planning I was perhaps a little more sensitive. But, I had to ask myself, was it really worth spending hours on something that was probably only good for a few months of accuracy? Sure, there are probably some events we need to reserve well in advance because others are asking for it. However, we really didn't know if we would do these events until we get closer. There were just too many unknowns in the equation and things that could happen between now and summer of 2008. Despite our best planning, we can't really predict what will happen to the day and time. Plus, we already know that the people will change and they may want to do some things differently later on.
That's the beauty with Agile. It puts a shorter "time box" on everything. Let's focus on the next few months with a greater precision in the short term, and intentionally leave the future as fuzzy as possible. When we absolutely have to make decisions, let's make them at the last responsible moment. All the time changing the plan to better reflect the current state of things. Then, when people change (or change their minds), you can change the plan with it. I don't know what I will be doing at 10 am on June 1st of 2008 but I can give you a better idea of what I will be doing in the next six weeks.
I don't place blame on the leader of this because she was doing what had been done before. It was my first time, and knowing the problems I have had in the past with long term software project planning I was perhaps a little more sensitive. But, I had to ask myself, was it really worth spending hours on something that was probably only good for a few months of accuracy? Sure, there are probably some events we need to reserve well in advance because others are asking for it. However, we really didn't know if we would do these events until we get closer. There were just too many unknowns in the equation and things that could happen between now and summer of 2008. Despite our best planning, we can't really predict what will happen to the day and time. Plus, we already know that the people will change and they may want to do some things differently later on.
That's the beauty with Agile. It puts a shorter "time box" on everything. Let's focus on the next few months with a greater precision in the short term, and intentionally leave the future as fuzzy as possible. When we absolutely have to make decisions, let's make them at the last responsible moment. All the time changing the plan to better reflect the current state of things. Then, when people change (or change their minds), you can change the plan with it. I don't know what I will be doing at 10 am on June 1st of 2008 but I can give you a better idea of what I will be doing in the next six weeks.
Wednesday, April 4, 2007
YAGNI is very lean
In Extreme Programming (XP), there is an accepted principle with the acronym of YAGNI. What is it? Here's a good summary from Wikipedia:
This principle very much supports both the concepts of Eliminating Waste and Defer Commitment. If you are not sure that code or functionality is really needed, you need to do some more homework. This homework could be additional research, talking with customers, or just waiting until you deliver higher priority functionality to the customer and really see if they need something else. In Lean, if there isn't direct Customer Value it is considered Waste. That is a bad thing. As mentioned above, it also leads to more complexity which can impact the long-term maintainability and quality of your code. Therefore, why not keep things as simple as possible until you absolutely need to put more into it?
I have seen in many design sessions where things get into a frenzy because the developers have figured out something cool with the technology they are using and are very eager to implement their ideas. This is fine, as long as the technology and their ideas translate into something the customer really wants or needs. Too many times, customers are usually forced into having something new that the development team thought they needed only to find they hardly use it. What happens next? Well, usually both the customer and the development team live with this unused, most likely complicated functionality forever. In the end, nobody is really happy about it.
However, when you find yourself in such a meeting (and you will at some point), remind the team about YAGNI. This will be a good reminder to them about the important of value and to wait until it is the right time to implement such functionality.
The YAGNI principle of software development says that when there's a good chance that "you ain't gonna need it", it's better to postpone adding a program feature.
Even when it turns out that the functionality really is needed, the habit of writing code that is not necessary at the moment has some overlooked disadvantages:
* The time spent is taken from necessary functionality.
* The new features must be debugged, documented, and supported.
* Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
* Until the feature is actually needed it is not possible to define what it should do, or to test it. This often results in such features not working right even if they eventually are needed.
* It leads to code bloat; the software becomes larger and more complicated while providing no more functionality.
* Unless there are specifications and some kind of revision control, the feature will never be known to programmers who could make use of it.
* Adding the new feature will inevitably suggest other new features. The result is a snowball effect which can consume unlimited time and resources for no benefit.
This principle very much supports both the concepts of Eliminating Waste and Defer Commitment. If you are not sure that code or functionality is really needed, you need to do some more homework. This homework could be additional research, talking with customers, or just waiting until you deliver higher priority functionality to the customer and really see if they need something else. In Lean, if there isn't direct Customer Value it is considered Waste. That is a bad thing. As mentioned above, it also leads to more complexity which can impact the long-term maintainability and quality of your code. Therefore, why not keep things as simple as possible until you absolutely need to put more into it?
I have seen in many design sessions where things get into a frenzy because the developers have figured out something cool with the technology they are using and are very eager to implement their ideas. This is fine, as long as the technology and their ideas translate into something the customer really wants or needs. Too many times, customers are usually forced into having something new that the development team thought they needed only to find they hardly use it. What happens next? Well, usually both the customer and the development team live with this unused, most likely complicated functionality forever. In the end, nobody is really happy about it.
However, when you find yourself in such a meeting (and you will at some point), remind the team about YAGNI. This will be a good reminder to them about the important of value and to wait until it is the right time to implement such functionality.
Tuesday, April 3, 2007
Go to the Source
In Lean, a key practice is one called "Go to the Gemba". Here's a brief description according to Wikipedia:
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.
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.
Monday, April 2, 2007
Certification and Agile: Are We There Yet?
I've always been a little skeptical around certifications. Why? Because I am not sure that the certification process is focused on what counts (experience) but what is easily obtainable (knowledge). Seems I'm not alone in that feeling. The Agile Alliance came out with their own viewpoint last week. Here's what they said:
I think there is a place for certification in Agile as it has worked for other technical certification processes such as PMI, Sun, Microsoft, and others. It's good to see that Agile is maturing to a point where certification is becoming important in hiring skilled people. However, it's just too easy for anybody to become a Certified Scrummaster. Just a two-day course and viola....you are certified. This does not guarantee that you are skilled in Scrum, have experience with teams, and understand Agile principles and practices. Perhaps some of the higher levels discussed above will demonstrate those skills.
Now that Agile software development is becoming a mainstream practice, more and more employers need to staff teams that will perform it well. How can they know if a particular person will be an asset? One way might be to favor employees who are vouched for by some certification body. It is the position of the board of the Agile Alliance that employers should have confidence only in certifications that are skill-based and difficult to achieve. We also believe that employers should not require certification of employees.
Certifications in our industry usually tell you that a person has been exposed to particular knowledge. Some certifications additionally tell you that she has passed a test on that knowledge. Knowledge is a wonderful thing, but businesses pay for performance. Performance requires skill. A skill is not as simple to acquire as knowledge: the learner has to perform the skill badly, recover from mistakes, do it a bit better, and keep repeating the whole process. Especially for the interrelated and interpersonal skills required of Agile software development, much of the learning has to take place on real projects. It is that learning that a certification should vouch for. Vouching for someone else’s skill requires close observation or questioning by someone already possessing it. For anything other than uninterestingly simple skills, that’s a lot of work–which means it’s expensive. Therefore, the only skills worth formally vouching for are those that require substantial effort to learn.
While a skill-based certification can shorten the hiring or promotion process, there are many skilled practitioners who are not certified. Excluding them from consideration would be a poor business decision. Moreover, the state of the practice moves on. Skills decay when unused. The question is not whether an applicant once possessed appropriate skill; it’s whether the applicant can do what’s required today. A certificate cannot substitute for the hard work of individual evaluation.
Certifications such as Certified Scrum Master and DSDM Foundation are knowledge-based and easy to achieve. We believe the courses that lead to them are good ones. We believe people who attend them get their money’s worth. But while the certifications may be evidence of good faith, useful knowledge, and a desire to learn, they are not in themselves evidence of skill. Higher levels of certification, such as DSDM Practitioner or Certified Scrum Practitioner, require project experience, a written project synopsis, and an oral examination. They are skill-based. Other organizations like the Agile Project Leadership Network are working on skill-based certifications. We applaud their efforts. Although, the position of Agile Alliance remains firmly that employers should not require certification of employees and that skill needs to be acquired by practice on agile projects not by training alone.
I think there is a place for certification in Agile as it has worked for other technical certification processes such as PMI, Sun, Microsoft, and others. It's good to see that Agile is maturing to a point where certification is becoming important in hiring skilled people. However, it's just too easy for anybody to become a Certified Scrummaster. Just a two-day course and viola....you are certified. This does not guarantee that you are skilled in Scrum, have experience with teams, and understand Agile principles and practices. Perhaps some of the higher levels discussed above will demonstrate those skills.
Subscribe to:
Posts (Atom)