Friday, March 23, 2007
Out for a week
Thanks to everyone who has been supportive and reading this blog. I will be out until Monday, April 2nd for vacation. However, I will be back and ready to provide more posts for your reading pleasure.
Games that you can plan with
Mike Griffiths from Leading Answers has a great post called "Release and Iteration Planning with Innovation Games". Here is his introduction:
Read more in his post on these three tools. Personally, I like tools like these especially for people who think more visually. Plus, by using stickers you have plenty of flexibility as you brainstorm with others and determine what the release will look like. I definitely plan on buying the book.
In this post I outline some really useful techniques for planning releases and iterations. They are adapted from a great book called “Innovation Games: Creating Breakthrough Products through Collaborative Play" by Luke Hohmann
I have never been a fan of suggesting the use of “games” in the enterprise workplace, as in XP’s “Planning Game”. The term does not sit well with some traditional-type folks; to them it sounds unprofessional and not serious enough for important work. Yet the Innovation Games described by Hohmann are high performance facilitated workshop exercises that produce great results. If the project is serious enough to engage busy stakeholders then I think we owe it to the business to use the most effective tools at our disposal. If calling them “facilitated workshop exercises” eases their acceptance then I’m all for it, because it is the results I’m really interested in, not so much what we call them.
In Luke’s book, he outlines a number of games (exercises) that can be used in a variety of settings. Some like “Design the Product Box” and “Buy a Feature” are probably familiar to many people working on agile projects, others will likely be new. To keep this post a reasonable length I will focus on adapting three exercises for use in release and iteration planning.
The three we will look at are “Remember the Future”, “Prune the Product Tree”, and “Speedboat”. I use slight variations on the last two, I call them “Shape the Product Tree” and “Sailboat” and I will explain the differences when we get to them...
Read more in his post on these three tools. Personally, I like tools like these especially for people who think more visually. Plus, by using stickers you have plenty of flexibility as you brainstorm with others and determine what the release will look like. I definitely plan on buying the book.
Thursday, March 22, 2007
Agile Project Leadership Network (APLN)
Leaders from the Agile community decided that something more should be said for those that manage agile and adaptive teams. Thus, Agile Project Leadership Network (APLN) was born. Here some information provided by their web site:
From a executive management perspective, this is great material to sell upper management on the business advantages of moving to agile or adaptive development. They think in terms of management, and understand less about the inner workings of an agile team (either because they don't relate or don't desire that level of detail). This still speaks to the core values of agile, but in terms management likes to hear (I highlighted those terms above). If you are a manager or trying to sell management on agile, check out the APLN. They have some excellent resources. If you want to attend a local chapter of APLN, you can find out if your city has one here.
APLN was founded in 2004 by a group of people who are active in writing about, practicing, and evangelizing the movement towards fast, flexible, customer value driven approaches to leading projects of many types. Although this organization is separate from the Agile Alliance, our intention is to work closely with that group within the software community, but also work with people and companies outside of software and IT to help them become better Project Leaders.
This group was also responsible for their own manifesto, called the Declaration of Interdependence (DOI). A group of managers, authors, consultants, and team members from different project and product domains came together to discover common ground with respect to Agile and Adaptive Management (Similar to the Agile Manifesto meeting of 2001). This group represented people from the software development community (Alistair Cockburn, Mike Cohn, Jim Highsmith), the product development community (Preston Smith), and the general project management community (Doug DeCarlo, Robert Wysocki). Six core values emerged from that collaboration:
1) We increase return on investment by making continuous flow of value our focus.
2) We deliver reliable results by engaging customers in frequent interactions and shared ownership.
3) We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
4) We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
5) We boost performance through group accountability for results and shared responsibility for team effectiveness.
6) We improve effectiveness and reliability through situationally specific strategies, processes and practices.
From a executive management perspective, this is great material to sell upper management on the business advantages of moving to agile or adaptive development. They think in terms of management, and understand less about the inner workings of an agile team (either because they don't relate or don't desire that level of detail). This still speaks to the core values of agile, but in terms management likes to hear (I highlighted those terms above). If you are a manager or trying to sell management on agile, check out the APLN. They have some excellent resources. If you want to attend a local chapter of APLN, you can find out if your city has one here.
Wednesday, March 21, 2007
What does it mean to be Lean?
Note: I wrote this post originally on my first blog, Random Thoughts from a CTO, but thought it was good enough to share with the readers here.
Lean can mean different things to different people.
For some, lean can refer to how you maintain your physical shape through dieting and exercise. For those that have been successful in staying lean, they will say that it takes a paradigm shift of how you take care of your body through what you eat and how you exercise. When you start the process of becoming lean, you begin to cut out those things that are unhealthy and make you fat. You begin to eat better. You begin to feel better. You start seeing results in the mirror. You also are constantly monitoring your weight, heartbeat, blood pressure, calories, etc through the process. For some of us, myself included, we get lazy once we reach this point and start falling back to bad habits -- at first, a mistake here and there on what we eat, or missing a workout or two. Then, you stop getting on the scale and recording your results. Then, before you know it you are not lean again!
For others, lean can refer to how you maintain your financial status through budgeting and tracking your expenses. For those that have been successful in saving money and making more through investing, they will say that it takes a paradigm shift of what you do with your money and where it goes. When you start the process of saving money, you begin to determine where your expenses are going and which of those expenses you can eliminate that takes you from your goals. You also look at ways to increase your income with those savings through investments. You also look to remove your debt. You begin to save money. You begin to feel better. You start seeing results in your portfolio. You also are constantly monitoring your income flow, expenses and net worth through the process. For some of us, in this case myself not included, we get lazy once we reach this point and start falling back to bad habits of spending excess money, getting into debt, and eventually not saving money. Then, before you know it you are not financially set again!
In the software engineering industry, lean is now referring to your cycle time - how quickly you get to a working solution for the end customer without losing quality. For those that have been successful with this approach, they will say that it takes a paradigm shift of how you development and manage your software solutions. When you start the process of reducing cycle times, you begin to determine where communication and collaboration need to happen, what activities or processes take away from reducing cycle times, how we do our jobs and the way we interact with other areas. You will begin to see results. You will see the customer is more satisfied. You will find better ways to get your work done. You also are constantly monitoring your estimates, work completed, costs, quality much better. For some of us, myself a little bit, it is very easy to fall back into old habits of traditional and formal processes because you are so familiar with them and may get discouraged early on in not seeing immediate results you are hoping. You then begin to see things slip, take longer and less of a feeling of accomplishment either by the team or the end customer. Then, before you know it you are feeling that things aren't getting done as they should!
There are many other scenarios that this lean approach can take - time management, stress management, strategy, project management, the list goes on and on. What is getting in the way of your goals? How do you improve on those goals? What do you do to maintain those goals? How do you measure the process of those goals?
Focus on the goals and maintain discipline to see it through! This is what lean should mean!
Lean can mean different things to different people.
For some, lean can refer to how you maintain your physical shape through dieting and exercise. For those that have been successful in staying lean, they will say that it takes a paradigm shift of how you take care of your body through what you eat and how you exercise. When you start the process of becoming lean, you begin to cut out those things that are unhealthy and make you fat. You begin to eat better. You begin to feel better. You start seeing results in the mirror. You also are constantly monitoring your weight, heartbeat, blood pressure, calories, etc through the process. For some of us, myself included, we get lazy once we reach this point and start falling back to bad habits -- at first, a mistake here and there on what we eat, or missing a workout or two. Then, you stop getting on the scale and recording your results. Then, before you know it you are not lean again!
For others, lean can refer to how you maintain your financial status through budgeting and tracking your expenses. For those that have been successful in saving money and making more through investing, they will say that it takes a paradigm shift of what you do with your money and where it goes. When you start the process of saving money, you begin to determine where your expenses are going and which of those expenses you can eliminate that takes you from your goals. You also look at ways to increase your income with those savings through investments. You also look to remove your debt. You begin to save money. You begin to feel better. You start seeing results in your portfolio. You also are constantly monitoring your income flow, expenses and net worth through the process. For some of us, in this case myself not included, we get lazy once we reach this point and start falling back to bad habits of spending excess money, getting into debt, and eventually not saving money. Then, before you know it you are not financially set again!
In the software engineering industry, lean is now referring to your cycle time - how quickly you get to a working solution for the end customer without losing quality. For those that have been successful with this approach, they will say that it takes a paradigm shift of how you development and manage your software solutions. When you start the process of reducing cycle times, you begin to determine where communication and collaboration need to happen, what activities or processes take away from reducing cycle times, how we do our jobs and the way we interact with other areas. You will begin to see results. You will see the customer is more satisfied. You will find better ways to get your work done. You also are constantly monitoring your estimates, work completed, costs, quality much better. For some of us, myself a little bit, it is very easy to fall back into old habits of traditional and formal processes because you are so familiar with them and may get discouraged early on in not seeing immediate results you are hoping. You then begin to see things slip, take longer and less of a feeling of accomplishment either by the team or the end customer. Then, before you know it you are feeling that things aren't getting done as they should!
There are many other scenarios that this lean approach can take - time management, stress management, strategy, project management, the list goes on and on. What is getting in the way of your goals? How do you improve on those goals? What do you do to maintain those goals? How do you measure the process of those goals?
Focus on the goals and maintain discipline to see it through! This is what lean should mean!
Monday, March 19, 2007
The Predictability Paradox
We had just several months earlier started our implementation of Scrum to all of our project teams. As we were learning what to do, more importantly we were learning things not to do. One of the things I found challenging in our adoption of Agile was that many felt that the traditional (Waterfall) way we were delivering software before was more predictable and that Scrum would be totally unpredictable given its emphasis on focusing one iteration to the next instead of heavy upfront requirements, design and planning. I knew in my heart that Waterfall really couldn't predict any better but really couldn't put my finger on why. It was then that I read this paper called "Lean Development and the Predictability Paradox" that I got my answer. It was this paper that changed my thinking and introduced the Lean concepts to apply to what I had already learned with Scrum. Here is the introduction (read more including more details on each aspect of Lean by downloading the paper here):
Wall Street has little sympathy for companies that can’t meet their forecasts every quarter. In turn, senior management expects department managers to make and meet forecasts. By the time these expectations arrive at an IT department, meeting forecasts often becomes a significant challenge. Unfortunately, it seems that a large fraction of software projects fail to deliver on their promises for one reason or another.
Why is it that software development projects seems to have so much difficulty delivering predictable outcomes? It seems that all too often projects are late or over budget or they deliver the wrong system or all of the above. How can the predictability of software development outcomes be increased? This executive report discusses a dilemma: in our zeal to improve the reliability of software development, we have institutionalized practices that decrease, rather than increase, the predictability of outcomes.
The best way to achieve predictable software development outcomes is to start early, learn constantly, commit late, and deliver fast. This may seem to cut against the grain of conventional project management practice, which is supposed to give more managed, predictable results. But predictability is a funny thing; you cannot build with confidence on a shifting foundation. The problem with conventional approaches is that they assume the foundation is firm; they have little tolerance for change.
The paradox is that trying too hard to create predictability creates opposite effect. Conventional practices are fragile in the face of change, and even in the face of learning. And yet, the more complex the system, the more necessary learning becomes. What is needed is an approach that encourages learning, and does not commit until learning is complete.
It should be obvious that decreasing the amount of speculation involved in making a decision increases predictability of the outcome. If you can make decisions based on facts rather than forecasts, you get results that are more predictable. Lean development is the art and discipline of basing commitments on facts rather than forecasts. It starts earlier, encourages change, freezes decisions later, and delivers faster than traditional practices, but nevertheless lean development produces outcomes that are more predictable.
The paradox of lean development is that you have give up some of the trappings of predictability in order to get true predictability. You have to abandon some conventional wisdom to gain the benefits of making decisions with more certainty. Fundamentally, you have to develop the capability to respond to events as they unfold, rather than hold dear the capability to orchestrate events in advance.
Friday, March 16, 2007
What part does Credibility play?
In both lean and agile cultures, it is important that teams are self-organizing, self-improving, and self-managing. To be able to do that requires a certain amount of autonomy and latitude to "do the right things". This in turn requires a certain amount of trust that the right things will happen and respect that the team and individuals on that team have the right knowledge and skills to accomplish the work. All of this requires establishing credibility.
What is credibility? I see credibility as a track record. Each person can have a good track record or a bad one. A good track record is one where the person says what they are going to do (integrity), their opinions are proven through implementation (knowledgeable), and their actions are in the best interest of the company (commitment). A bad track record is one where one or more of these components are consistently being challenged by others. "Is this person representing the company?" "Do they know what they are doing?" "Will they really follow through and deliver?" If these and other questions continue to happen, this will impact the credibility of not just particular individuals but eventually the team as a whole.
Why all of this talk around credibility? Because if you want good communication between customers and the development team you need credibility. If you want the team to think in Lean concepts and perform in an Agile manner, they must have an appropriate level of credibility at some point. This isn't just an Agile or Lean thing, the same can be said about any employee, department or project team. It's just much more apparent and critical with Lean and Agile since the focus is on teamwork and the role of teams.
Whenever you have your next brainstorming or design session, look around and listen to what people are saying and how others are reacting. If you hear things that are based on little fact, make sure that work is done afterwards to experiment and prove out the theories and assumptions. If you see that others are showing through their words (and more importantly their body language) that they don't believe individuals or even worse the team, talk to those people and coach them on credibility. Make sure they see examples that hurt credibility as well as those that improve it.
As a manager, I am highly sensitive to the reputation of people, teams or the entire department. Typically, credibility and reputation go hand-in-hand. I want individuals to be successful. I want trust and respect established. I want them to have the highest integrity. Each of them should want it just as bad. Many times, they may not know why they aren't getting it. Credibility isn't something that is easily given, it must be earned. It is something that is earned over your lifetime. Think about that for a moment...
What is credibility? I see credibility as a track record. Each person can have a good track record or a bad one. A good track record is one where the person says what they are going to do (integrity), their opinions are proven through implementation (knowledgeable), and their actions are in the best interest of the company (commitment). A bad track record is one where one or more of these components are consistently being challenged by others. "Is this person representing the company?" "Do they know what they are doing?" "Will they really follow through and deliver?" If these and other questions continue to happen, this will impact the credibility of not just particular individuals but eventually the team as a whole.
Why all of this talk around credibility? Because if you want good communication between customers and the development team you need credibility. If you want the team to think in Lean concepts and perform in an Agile manner, they must have an appropriate level of credibility at some point. This isn't just an Agile or Lean thing, the same can be said about any employee, department or project team. It's just much more apparent and critical with Lean and Agile since the focus is on teamwork and the role of teams.
Whenever you have your next brainstorming or design session, look around and listen to what people are saying and how others are reacting. If you hear things that are based on little fact, make sure that work is done afterwards to experiment and prove out the theories and assumptions. If you see that others are showing through their words (and more importantly their body language) that they don't believe individuals or even worse the team, talk to those people and coach them on credibility. Make sure they see examples that hurt credibility as well as those that improve it.
As a manager, I am highly sensitive to the reputation of people, teams or the entire department. Typically, credibility and reputation go hand-in-hand. I want individuals to be successful. I want trust and respect established. I want them to have the highest integrity. Each of them should want it just as bad. Many times, they may not know why they aren't getting it. Credibility isn't something that is easily given, it must be earned. It is something that is earned over your lifetime. Think about that for a moment...
Thursday, March 15, 2007
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:
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.
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.
Wednesday, March 14, 2007
Transparency is the key
Recently, we did a retrospective at the end of one of our iterations. As part of this process, we show a working demo of functionality that has been completed as part of that iteration. Usually, this goes pretty well but this one didn't end up as well.
During the demo, things started out smoothly. We demonstrated the functionality and everybody was pleased with the results. It was the conversation that happened afterwards where things went downhill.
Those that were representing the customer wanted to know about some functionality that had been talked about but hadn't been completed yet. The Developers assumed that the Customers were accusing the team of not delivering something yet. They got on the defensive quickly saying such things as "That functionality wasn't part of the scope of the project" and "I wasn't tasked with that work so I know nothing about those requirements" and "I don't remember those conversations" and "I thought it was part of a future project". What's was interesting is that none of these conversations were really true, but they were used as a defense mechanism. Once these things were uttered, the Customers also became defensive. "What else have you forgotten?" "Have you even thought about these things?" "Will the current solution accomodate this new functionality that is added later?" "When are these requirements being considered, if at all?"
After we ended the meeting, I met with the Project Manager/Scrum Master who had also attended the meeting to recap. She was as surprised as me to the statements that were made and was a little upset that the Developers had acted that way. I went to talk to the Customers and she went to talk to the Developers. Here's what we learned...
The Developers knew the right answers but felt they were been questioned for things that they weren't focusing on at the moment. So, they tried to do a little CYA for their lack of knowledge with the questions. Instead, they could have easier said to the Customers, "Though we have talked about that functionality, we haven't really focused on it because the functionality that you saw today needed to be completed first (because it was core and highest value). The Scrum Master could have talked about when those discussions would happen. In my talking with Customers, they knew what was being shown and understood the team was to deliver what they saw but just wanted to know how much thought had been given to the design and implementation so far to the next functionality that is being considered. It was an honest question that should have had an honest question. Instead, the Developers interpreted the question as blame for not having more to show in the demo.
I realized that there is still much work to be done to encourage transparency between Customers and Developers. It is ok to discuss roadblocks and issues between groups as they happen. Bad news shouldn't be hidden. It is ok to discuss that there are things that haven't received the focus on the team yet. It is ok to discuss changes and new ideas that weren't part of the original conversations. We should encourage feedback (good or bad). We should encourage honesty in where we are at. If this is done, it will establish better trust and respect between these groups and a healthy relationship will grow. Perhaps we are dealing with years in which Customers and Developers didn't spend much time together and the relationship was strained and distant as the result. When they got together, it was more like contract negotiation across the table than a partnership with much collaboration.
In the end, I was glad to see that this happened and know how to coach others in better communication in the future. Retrospectives are to be a checkpoint on where you are at in the delivery of work. Not just a checkpoint on what you deliver but also how you deliver it. The process is just as important as the deliverables. Both need feedback and constant improvement based on each "checkpoint". This is one of the key benefits of Agile -- to embrace changes based on constant feedback towards providing better customer and business value. How you work with others is a big part of that.
During the demo, things started out smoothly. We demonstrated the functionality and everybody was pleased with the results. It was the conversation that happened afterwards where things went downhill.
Those that were representing the customer wanted to know about some functionality that had been talked about but hadn't been completed yet. The Developers assumed that the Customers were accusing the team of not delivering something yet. They got on the defensive quickly saying such things as "That functionality wasn't part of the scope of the project" and "I wasn't tasked with that work so I know nothing about those requirements" and "I don't remember those conversations" and "I thought it was part of a future project". What's was interesting is that none of these conversations were really true, but they were used as a defense mechanism. Once these things were uttered, the Customers also became defensive. "What else have you forgotten?" "Have you even thought about these things?" "Will the current solution accomodate this new functionality that is added later?" "When are these requirements being considered, if at all?"
After we ended the meeting, I met with the Project Manager/Scrum Master who had also attended the meeting to recap. She was as surprised as me to the statements that were made and was a little upset that the Developers had acted that way. I went to talk to the Customers and she went to talk to the Developers. Here's what we learned...
The Developers knew the right answers but felt they were been questioned for things that they weren't focusing on at the moment. So, they tried to do a little CYA for their lack of knowledge with the questions. Instead, they could have easier said to the Customers, "Though we have talked about that functionality, we haven't really focused on it because the functionality that you saw today needed to be completed first (because it was core and highest value). The Scrum Master could have talked about when those discussions would happen. In my talking with Customers, they knew what was being shown and understood the team was to deliver what they saw but just wanted to know how much thought had been given to the design and implementation so far to the next functionality that is being considered. It was an honest question that should have had an honest question. Instead, the Developers interpreted the question as blame for not having more to show in the demo.
I realized that there is still much work to be done to encourage transparency between Customers and Developers. It is ok to discuss roadblocks and issues between groups as they happen. Bad news shouldn't be hidden. It is ok to discuss that there are things that haven't received the focus on the team yet. It is ok to discuss changes and new ideas that weren't part of the original conversations. We should encourage feedback (good or bad). We should encourage honesty in where we are at. If this is done, it will establish better trust and respect between these groups and a healthy relationship will grow. Perhaps we are dealing with years in which Customers and Developers didn't spend much time together and the relationship was strained and distant as the result. When they got together, it was more like contract negotiation across the table than a partnership with much collaboration.
In the end, I was glad to see that this happened and know how to coach others in better communication in the future. Retrospectives are to be a checkpoint on where you are at in the delivery of work. Not just a checkpoint on what you deliver but also how you deliver it. The process is just as important as the deliverables. Both need feedback and constant improvement based on each "checkpoint". This is one of the key benefits of Agile -- to embrace changes based on constant feedback towards providing better customer and business value. How you work with others is a big part of that.
Tuesday, March 13, 2007
The Agile Elevator Speech
I was going to also call this post, "How to talk about Agile to the non-Agile" but thought the title above was more appropriate. Joe Little from Agile and Business blog has a post was trying to figure out how to tell friends and family about what Agile and Lean are without having to spend a lot of time getting them up to speed. In his post, he ends up summarizing it as:
I think this is an excellent introduction to both Agile and Lean that can be accomplished in a few minutes and give the listener an idea without having to know much about software development, product development or manufacturing. Read more in his post on how he led up to this list.
* Focus on delivering small slices of concrete business value frequently (1-4 weeks)
* Work with a small team of people, to enable them to be as productive as possible
* Use concrete, understandable results to allow all parties to adapt and move forward
* Arrange things so that change and learning are benefits
* Tell the truth, and make the important things as visible as possible
* Minimize waste and extra effort; maximize customer value, don't impress with hard work
I think this is an excellent introduction to both Agile and Lean that can be accomplished in a few minutes and give the listener an idea without having to know much about software development, product development or manufacturing. Read more in his post on how he led up to this list.
Monday, March 12, 2007
What kind of person do you need for Agile?
What kind of people does it take to be successful with Agile? I have learned that there are some attributes that are critical for success. If you don't have many if not most of these qualities, you or your team will suffer the consequences. As you are developing your team (and perhaps hiring people outside of your company) think about these things as you are determining who will be on your Agile teams:
Team Player - Agile is focused around communication and collaboration with other team members. If you can't play well with others, you will have a difficult time. If you are uncomfortable communicating within a team, you need to get out of your comfort zone. You are not doing Agile if you sit somebody in a corner to code.
Disciplined - Many people when seeing Agile for the first time think it is very informal and therefore undisciplined. I have experienced first hand that it takes a lot of discipline. There is never really down time. With shorter iterations, every minute really counts. You must be organized with your time. You must think how to be more efficient. You must constantly be thinking about the architecture, how to test, how to redesign, integration, builds. These can happen on at least a daily basis if not more frequently. This takes discipline!
Adaptable - As Agile requires the flexibility in the process to embrace change, so should each individual have the same approach. Processes will be constantly improving. Code and design will be changing. Customers will have the opportunity to change their minds more often. If you don't like change, you will have difficulty with Agile. You must accept that change will happen and prepare for it mentally.
Takes Initiative - Agile requires that the team be aware of not only what the customer needs but always looking for ways to improve the quality of the deliverables. Creating tests, looking at design, code review, refactoring takes initiative. Each person is expected to tell the team what needs to happen and sign up for tasks along the way. That takes initiative!
Self-managed - Though most Agile teams have some kind of manager or coach present, whether that be a Project Manager, Scrum Master, or Agile Coach, the ultimate goal is for the team to be self-organizing. If management is present, it is only there as help from the team to remove impediments and may be involved to report progress to stakeholders outside of the team. The team is responsible for taking what the customer wants and delivering it in increments. They must figure out how best to work as a team, who is going to take what, and know that each person is responsible for the team's success. In order to do this, each person cannot require somebody to assign tasks and have that person check progress. They can't be micro-managed but need to manage themselves against the team.
Experienced - Though Agile can work with some members of the team being junior-level, it does require experience from most of the team. Experience will technical skills. Experience with "soft" skills. Experience with Agile. Experience with the domain (customers, industries, products, services). The team will do better with the confidence that comes with experience. It is also crucial that junior-level people get up to speed quickly so they don't slow the team down. By developing in small increments and using techniques such as pair-programming, this can make the learning curve smoother.
Customer/Business Minded - Though most Agile teams have a dedicated customer, it doesn't free the team up to not worry about what the customer wants. In fact, I would say that Agile forces you to put yourself in the customer's shoes. "Am I doing what the customer wants?" "Does what I provide help the customer's business?" "Are there ways to help the customer be more successful?" I have seen people on teams who could care less about the customer but just want to go do their work. In the long term, this really won't work with Agile. Since everything is around prioritizing the work based on customer value, you can't be effective if you aren't thinking about the customer.
Did I cover them all? What other attributes can you think of that individuals need to possess?
Team Player - Agile is focused around communication and collaboration with other team members. If you can't play well with others, you will have a difficult time. If you are uncomfortable communicating within a team, you need to get out of your comfort zone. You are not doing Agile if you sit somebody in a corner to code.
Disciplined - Many people when seeing Agile for the first time think it is very informal and therefore undisciplined. I have experienced first hand that it takes a lot of discipline. There is never really down time. With shorter iterations, every minute really counts. You must be organized with your time. You must think how to be more efficient. You must constantly be thinking about the architecture, how to test, how to redesign, integration, builds. These can happen on at least a daily basis if not more frequently. This takes discipline!
Adaptable - As Agile requires the flexibility in the process to embrace change, so should each individual have the same approach. Processes will be constantly improving. Code and design will be changing. Customers will have the opportunity to change their minds more often. If you don't like change, you will have difficulty with Agile. You must accept that change will happen and prepare for it mentally.
Takes Initiative - Agile requires that the team be aware of not only what the customer needs but always looking for ways to improve the quality of the deliverables. Creating tests, looking at design, code review, refactoring takes initiative. Each person is expected to tell the team what needs to happen and sign up for tasks along the way. That takes initiative!
Self-managed - Though most Agile teams have some kind of manager or coach present, whether that be a Project Manager, Scrum Master, or Agile Coach, the ultimate goal is for the team to be self-organizing. If management is present, it is only there as help from the team to remove impediments and may be involved to report progress to stakeholders outside of the team. The team is responsible for taking what the customer wants and delivering it in increments. They must figure out how best to work as a team, who is going to take what, and know that each person is responsible for the team's success. In order to do this, each person cannot require somebody to assign tasks and have that person check progress. They can't be micro-managed but need to manage themselves against the team.
Experienced - Though Agile can work with some members of the team being junior-level, it does require experience from most of the team. Experience will technical skills. Experience with "soft" skills. Experience with Agile. Experience with the domain (customers, industries, products, services). The team will do better with the confidence that comes with experience. It is also crucial that junior-level people get up to speed quickly so they don't slow the team down. By developing in small increments and using techniques such as pair-programming, this can make the learning curve smoother.
Customer/Business Minded - Though most Agile teams have a dedicated customer, it doesn't free the team up to not worry about what the customer wants. In fact, I would say that Agile forces you to put yourself in the customer's shoes. "Am I doing what the customer wants?" "Does what I provide help the customer's business?" "Are there ways to help the customer be more successful?" I have seen people on teams who could care less about the customer but just want to go do their work. In the long term, this really won't work with Agile. Since everything is around prioritizing the work based on customer value, you can't be effective if you aren't thinking about the customer.
Did I cover them all? What other attributes can you think of that individuals need to possess?
Friday, March 9, 2007
Challenging how some are using Scrum
Tobias Meyer is challenging how some are using Scrum and has proposed some different ideas based on his experience. His post called "When Scrum is not Scrum" is bound to generate some discussion in the Scrum community. I have summarized below each of his points, followed by my own experience around each:
1. Product Owners are part of the team. Product representative (not owner) should attend the daily meetings, retrospective, planning and review meetings.
Skip: There are a couple of thoughts in this bullet. Is the term Product Owner accurate? Do they really OWN the product? I have never liked the terms Product Manager and Product Owner because I don't believe that one person truly can own or manage a software product. Especially in an Agile environment where there is such emphasis on teamwork. In the training I recently attended, a new term called Product Champion was introduced. While this person does represent customers, their main role is to provide vision, passion and support of the team as the product is being developed. The other thought is How often should this person be involved in the team. People who play the customer role typically have limited time with the team (I would love to have a full-time customer available!), so we have tried to include them in just the planning and retrospective meetings. We have had some success but have also realized that something is definitely missing. We end up spending time discussing decisions that the team made on a daily basis on behalf of the customer. Not only does this take additional time (I would consider Waste in Lean terms) but also some rework if our assumptions were wrong. Perhaps there is a point that more involvement needs to be made.
2. Two-week Sprints. Teams are incapable of planning a thirty-day sprint effectively. It is overwhelming. Most teams I have tried it nail the first part of the sprint, but allow the second part to be vague and muddy.
Skip: I totally agree. In fact, it seems that most people using Scrum are doing 2 or 3 week iterations and those that are experienced are going with 1 week iterations. We tried one month iterations and experienced the same issues. We have found that 2 weeks provide the right amount of scope balanced against the right amount of workload/urgency needed.
3. Tasks are not measured in hours. Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach. In my experience team members find this practice frustrating and meaningless. Long ago I moved towards encouraging team members to break all tasks down as small as possible. A task must be completed in a single working day or it is considered an impediment, and should be marked as such.
Skip: We tried at first to use points instead of hours for tasks. And by we, we are talking Management not the team. It was actually the team who felt more comfortable with looking at tasks in hours. So, at least our experience is the opposite of Tobias. I also look at tasks as a way to identify how the team is going to implement a story. Stories typically are defined between 1/2 to 3 days. We find it has been easiest many of these times to define just one task per team member who is contributing to the story because the size really is manageable. I'm just don't agree that these tasks have been completed as part of a day.
4. Use of Taskboards rather than spreadsheets. Spreadsheets hide information, and they lie. The best way to create transparency is to display everything on Big Visible Charts. The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.
Skip: We have been using an electronic solution and are finding ourselves liking the Taskboard approach better for some things and more difficult for others. It's better to ensure that the team is collaborating and taking ownership of the board. If it's in another format the responsibility has fallen more on the Scrum Master to maintain. What we have liked about the electronic format is that it is more portable (we don't have a dedicated room for each team - yet!) and it provides a good archive and easier ways to calculate burn down charts than the taskboard approach.
5. Backlogs on the wall. At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time. Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.
Skip: We have talked about this, and may go in this direction but again it's a matter of having dedicated space to have this much information on the walls. Having backlogs for the product has been helpful storing in an electronic format so that we have records of things that we aren't doing in the next couple of iterations but plan on looking at beyond that. We don't release every iteration, yet we also don't plan the entire release at this point. We also need a repository for discussion of future releases at least at a high-level as a roadmap of where we are taking our products. Not sure all of these things can be accomplished with backlogs on the wall.
6. Estimation Meetings. Estimation is done before the first sprint, and then on a regular basis during each sprint. I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time. Estimates are done in Story Points, as described in Mike Cohn’s books (not “ideal developer days” as described in the Scrum books).
Skip: Totally agree but we have not been consistent with this approach. I love the idea of using points to provide relative size of features or stories against each other. Better than t-shirt sizing, but not requiring the depth and time of getting to an hour estimate especially as you are looking at the next couple of iterations. I have also liked Mike's approach of using Estimating Cards with the team as a way for the team to come up with these estimates instead of individuals.
7. Insistence on Agile Engineering practices. It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start. Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.
Skip: I never really thought Scrum was to address engineering practices. I'm pretty sure Tobias isn't saying that it was, but the point that is that is all you are doing with a software product you are NOT fully taking available of the benefits that Agile can provide. We are seeing this first hand as we have much work on the engineering practices side to allow us to be more successful with our iterations. So, I TOTALLY agree with Tobias on this point.
8. The Scrum Master role is not always necessary. An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to. The Scrum Master role becomes superfluous in a healthy Agile organization.
Skip: I have been wondering this myself. I don't know if we are experienced enough to do this on a full-time basis, but I have seen evidence that this can work. We have had our Scrum Master out for periods of time either sick, training or vacation. On a couple of times, she has been out for at least half an iteration. So you would think that the iteration would have problems, right? Wrong! The team conducts their own daily meetings and figures out how to remove impediments and keep committed to the iteration. It's not the perhaps the Scrum Master role isn't necessary, it just means that it doesn't necessarily have to come from a particular person playing the role.
1. Product Owners are part of the team. Product representative (not owner) should attend the daily meetings, retrospective, planning and review meetings.
Skip: There are a couple of thoughts in this bullet. Is the term Product Owner accurate? Do they really OWN the product? I have never liked the terms Product Manager and Product Owner because I don't believe that one person truly can own or manage a software product. Especially in an Agile environment where there is such emphasis on teamwork. In the training I recently attended, a new term called Product Champion was introduced. While this person does represent customers, their main role is to provide vision, passion and support of the team as the product is being developed. The other thought is How often should this person be involved in the team. People who play the customer role typically have limited time with the team (I would love to have a full-time customer available!), so we have tried to include them in just the planning and retrospective meetings. We have had some success but have also realized that something is definitely missing. We end up spending time discussing decisions that the team made on a daily basis on behalf of the customer. Not only does this take additional time (I would consider Waste in Lean terms) but also some rework if our assumptions were wrong. Perhaps there is a point that more involvement needs to be made.
2. Two-week Sprints. Teams are incapable of planning a thirty-day sprint effectively. It is overwhelming. Most teams I have tried it nail the first part of the sprint, but allow the second part to be vague and muddy.
Skip: I totally agree. In fact, it seems that most people using Scrum are doing 2 or 3 week iterations and those that are experienced are going with 1 week iterations. We tried one month iterations and experienced the same issues. We have found that 2 weeks provide the right amount of scope balanced against the right amount of workload/urgency needed.
3. Tasks are not measured in hours. Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach. In my experience team members find this practice frustrating and meaningless. Long ago I moved towards encouraging team members to break all tasks down as small as possible. A task must be completed in a single working day or it is considered an impediment, and should be marked as such.
Skip: We tried at first to use points instead of hours for tasks. And by we, we are talking Management not the team. It was actually the team who felt more comfortable with looking at tasks in hours. So, at least our experience is the opposite of Tobias. I also look at tasks as a way to identify how the team is going to implement a story. Stories typically are defined between 1/2 to 3 days. We find it has been easiest many of these times to define just one task per team member who is contributing to the story because the size really is manageable. I'm just don't agree that these tasks have been completed as part of a day.
4. Use of Taskboards rather than spreadsheets. Spreadsheets hide information, and they lie. The best way to create transparency is to display everything on Big Visible Charts. The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.
Skip: We have been using an electronic solution and are finding ourselves liking the Taskboard approach better for some things and more difficult for others. It's better to ensure that the team is collaborating and taking ownership of the board. If it's in another format the responsibility has fallen more on the Scrum Master to maintain. What we have liked about the electronic format is that it is more portable (we don't have a dedicated room for each team - yet!) and it provides a good archive and easier ways to calculate burn down charts than the taskboard approach.
5. Backlogs on the wall. At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time. Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.
Skip: We have talked about this, and may go in this direction but again it's a matter of having dedicated space to have this much information on the walls. Having backlogs for the product has been helpful storing in an electronic format so that we have records of things that we aren't doing in the next couple of iterations but plan on looking at beyond that. We don't release every iteration, yet we also don't plan the entire release at this point. We also need a repository for discussion of future releases at least at a high-level as a roadmap of where we are taking our products. Not sure all of these things can be accomplished with backlogs on the wall.
6. Estimation Meetings. Estimation is done before the first sprint, and then on a regular basis during each sprint. I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time. Estimates are done in Story Points, as described in Mike Cohn’s books (not “ideal developer days” as described in the Scrum books).
Skip: Totally agree but we have not been consistent with this approach. I love the idea of using points to provide relative size of features or stories against each other. Better than t-shirt sizing, but not requiring the depth and time of getting to an hour estimate especially as you are looking at the next couple of iterations. I have also liked Mike's approach of using Estimating Cards with the team as a way for the team to come up with these estimates instead of individuals.
7. Insistence on Agile Engineering practices. It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start. Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.
Skip: I never really thought Scrum was to address engineering practices. I'm pretty sure Tobias isn't saying that it was, but the point that is that is all you are doing with a software product you are NOT fully taking available of the benefits that Agile can provide. We are seeing this first hand as we have much work on the engineering practices side to allow us to be more successful with our iterations. So, I TOTALLY agree with Tobias on this point.
8. The Scrum Master role is not always necessary. An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to. The Scrum Master role becomes superfluous in a healthy Agile organization.
Skip: I have been wondering this myself. I don't know if we are experienced enough to do this on a full-time basis, but I have seen evidence that this can work. We have had our Scrum Master out for periods of time either sick, training or vacation. On a couple of times, she has been out for at least half an iteration. So you would think that the iteration would have problems, right? Wrong! The team conducts their own daily meetings and figures out how to remove impediments and keep committed to the iteration. It's not the perhaps the Scrum Master role isn't necessary, it just means that it doesn't necessarily have to come from a particular person playing the role.
Thursday, March 8, 2007
List of Lean Resources
In my constant search for more information on Lean and Agile, especially around Software development, I found an excellent list put together by Brad Appleton and his ACME blog. The list is broken down by books, presentations, articles and websites/blogs (mine hadn't started yet or I'm sure Brad would have included me on the list).
You can find the list here. Also, Brad has accumulated quite a blogroll on various topics (which does have my two blogs and many others that I recommend and read often).
This should keep you busy for some time. I've got some reading to do now...
You can find the list here. Also, Brad has accumulated quite a blogroll on various topics (which does have my two blogs and many others that I recommend and read often).
This should keep you busy for some time. I've got some reading to do now...
Wednesday, March 7, 2007
Myths about Developers
In our process of implementing Agile and Lean, I have realized that there are things said or thought of about developers that Agile/Lean are showing as myths. If you still believe these statements are correct (or have developers believing them as well), you need to change your thinking if you want to adopt Agile/Lean. I used to believe some of these myself until I was surprised to find something much different.
Myth 1: Developers make poor testers. We established an entire QA department based on this myth. Developers don't like to test. Developers don't know how to do it. Developers are too close to their code. Developers should not test their own work. We said these things thinking that testing was a unique skill that could only be taught to non-developer types. What we realized is that these skills can be taught to anyone but few developers really know how to think about tests. The value of QA (or other testers) is to make sure that multiple people validate the test results. Two heads are better than one.
Myth 2: Developers do not work well in teams. It is thought that most developers by nature are introverted, and would rather go off and work in the corner than interact with others. Therefore, they we thought they would have a hard time with the teamwork that is required of Agile and Lean. What we realized is that developers just want to make sure there is value working in teams and they will come out of the comfort zones if it makes sense to accomplish more as a team. I will agree that for some this is an easier process than others, but eventually I have seen all developers warm up to working with others on a team.
Myth 3: Developers are not good in front of customers. Developers are too technical for customers. They talk above their heads. They don't have great communication skills. They are too brash and abrupt. They don't really care about what the customer wants. These are things that I have heard (and perhaps even said). However, just like testing Developers just haven't received the proper training and experience to work with customers. For most, it isn't natural to them. But, if you have them working often with customers they learn quickly. The customers also learn how to adapt to working with technical people. In the process, they learn the value of some of the "technical talk". Agile/Lean forces everyone to think in terms of the customer and working more directly with customers (or customer representatives).
Myth 4: Developers only care about coding. I just want to get back to my real job. When we used to use Waterfall, I would hear these words ALL the time from developers. After spending days and days in requirements and design meetings, I couldn't really blame them. However, I knew the value that they brought to those meetings in addition to the knowledge they gained to do a better job of coding. Agile helps developers get to coding more often, which is what they love. While at the same time, they appreciate the time to understand what needs to be accomplished. It's now the time it takes to do that is in matter of minutes or hours instead of days and weeks (and sometimes months!).
Myth 5: Developers want everything figured out at once. As we first implemented Agile, I got some push back from Developers that doing things in pieces would lead to poor architectures, design, missing requirements, etc. With Waterfall, they believed that they were able to get all of those right at the beginning of each project. However, I reminded them that pretty much every project we found changing requirements which lead to changing design which lead to changing architecture. So really how valuable was it to figure everything out in the front?? With that question posed, they gave it a try. And found that they could more easily adjust architecture, design, code by working on things in increments.
Myth 6: Developers cannot self-organize or self-improve. As a manager, this is where I really learned that this was a myth. I honestly thought that project managers and myself as a functional manager needed to be there to identify where improvements needed to be made and make the team implement those improvements (whether or not they truly understand the improvements). As a result, the team became dependent on management to make things better. Those dependencies became bottlenecks, because we would try to implement big changes instead of a lot of little changes. I also thought it was management's job to help assign tasks to people and make sure those people stayed on task. Again, this caused more bottlenecks. Here, the role of management was to REMOVE bottlenecks, yet we were BECOMING the bottleneck. All because of this notion that developers needed management to do these things for them. What developers really needed was practices that provided them the focus, direction, feedback and autonomy to do their work well. They are in the best place to know how to do their jobs well, so shouldn't they be the ones who figure out how best to accomplish that? When management backs off and the teams realize that it is their responsibility to improve things, they will do so. Plus, in the process they will feel better about themselves, their role in the company and their feelings about management.
Myth 1: Developers make poor testers. We established an entire QA department based on this myth. Developers don't like to test. Developers don't know how to do it. Developers are too close to their code. Developers should not test their own work. We said these things thinking that testing was a unique skill that could only be taught to non-developer types. What we realized is that these skills can be taught to anyone but few developers really know how to think about tests. The value of QA (or other testers) is to make sure that multiple people validate the test results. Two heads are better than one.
Myth 2: Developers do not work well in teams. It is thought that most developers by nature are introverted, and would rather go off and work in the corner than interact with others. Therefore, they we thought they would have a hard time with the teamwork that is required of Agile and Lean. What we realized is that developers just want to make sure there is value working in teams and they will come out of the comfort zones if it makes sense to accomplish more as a team. I will agree that for some this is an easier process than others, but eventually I have seen all developers warm up to working with others on a team.
Myth 3: Developers are not good in front of customers. Developers are too technical for customers. They talk above their heads. They don't have great communication skills. They are too brash and abrupt. They don't really care about what the customer wants. These are things that I have heard (and perhaps even said). However, just like testing Developers just haven't received the proper training and experience to work with customers. For most, it isn't natural to them. But, if you have them working often with customers they learn quickly. The customers also learn how to adapt to working with technical people. In the process, they learn the value of some of the "technical talk". Agile/Lean forces everyone to think in terms of the customer and working more directly with customers (or customer representatives).
Myth 4: Developers only care about coding. I just want to get back to my real job. When we used to use Waterfall, I would hear these words ALL the time from developers. After spending days and days in requirements and design meetings, I couldn't really blame them. However, I knew the value that they brought to those meetings in addition to the knowledge they gained to do a better job of coding. Agile helps developers get to coding more often, which is what they love. While at the same time, they appreciate the time to understand what needs to be accomplished. It's now the time it takes to do that is in matter of minutes or hours instead of days and weeks (and sometimes months!).
Myth 5: Developers want everything figured out at once. As we first implemented Agile, I got some push back from Developers that doing things in pieces would lead to poor architectures, design, missing requirements, etc. With Waterfall, they believed that they were able to get all of those right at the beginning of each project. However, I reminded them that pretty much every project we found changing requirements which lead to changing design which lead to changing architecture. So really how valuable was it to figure everything out in the front?? With that question posed, they gave it a try. And found that they could more easily adjust architecture, design, code by working on things in increments.
Myth 6: Developers cannot self-organize or self-improve. As a manager, this is where I really learned that this was a myth. I honestly thought that project managers and myself as a functional manager needed to be there to identify where improvements needed to be made and make the team implement those improvements (whether or not they truly understand the improvements). As a result, the team became dependent on management to make things better. Those dependencies became bottlenecks, because we would try to implement big changes instead of a lot of little changes. I also thought it was management's job to help assign tasks to people and make sure those people stayed on task. Again, this caused more bottlenecks. Here, the role of management was to REMOVE bottlenecks, yet we were BECOMING the bottleneck. All because of this notion that developers needed management to do these things for them. What developers really needed was practices that provided them the focus, direction, feedback and autonomy to do their work well. They are in the best place to know how to do their jobs well, so shouldn't they be the ones who figure out how best to accomplish that? When management backs off and the teams realize that it is their responsibility to improve things, they will do so. Plus, in the process they will feel better about themselves, their role in the company and their feelings about management.
Tuesday, March 6, 2007
Making things more difficult than they need to be
One of my IT guys told me an interesting story at lunch today.
He got an email from a person in our organization, it went something like this:
Person: "I have a problem. I have email that needs to go to another group of people after I have reviewed it. However, when I get the email it has the wrong people I want to send it to, so I need it to remove some groups or individuals and leave other groups. Please fix this for me."
IT: "What would you like me to do?"
Person: "I need a script or something that will change these email addresses from one group or individuals to another anytime these kinds of emails come up. Do you have time to do that for me?"
IT: "Is there a different way you can do it?"
Person: "If you don't have time, I understand but if you can just give me some guidance I will write the script myself."
IT: "Before we go down that road, could you give me more detail of what you want?"
Person: "Well, I receive these emails. Then I need to sometimes send these email to others groups. So, I select "Reply to All". Then I type in the new group of who I want to give it to. But, it also gives me the email addresses of everybody that saw the email beforehand."
IT: "Have you tried selecting "Forward" instead of "Reply to All"? Then you only have to specify the groups you need it to go to?"
This is a TRUE story, I'm really not making this stuff up. However, it shows how quickly we think we need to create another solution when the obvious solution is right in front of us. In this case, the person know how to forward email but had made up his mind that he was doing it the right way but the email reader wasn't working the way he expected. To fix the problem (it surely couldn't have been him, it had to be something else!), unnecessary time could have been spent creating a script.
I wonder if this happens the same way with products. We quickly expect that the products don't work and try to make them do something different as a result. We don't realize that perhaps we just don't understand how the product was designed. Once we do understand that, we may realize that the product is actually working as it should!
Anyways, I couldn't resist passing along this story!
He got an email from a person in our organization, it went something like this:
Person: "I have a problem. I have email that needs to go to another group of people after I have reviewed it. However, when I get the email it has the wrong people I want to send it to, so I need it to remove some groups or individuals and leave other groups. Please fix this for me."
IT: "What would you like me to do?"
Person: "I need a script or something that will change these email addresses from one group or individuals to another anytime these kinds of emails come up. Do you have time to do that for me?"
IT: "Is there a different way you can do it?"
Person: "If you don't have time, I understand but if you can just give me some guidance I will write the script myself."
IT: "Before we go down that road, could you give me more detail of what you want?"
Person: "Well, I receive these emails. Then I need to sometimes send these email to others groups. So, I select "Reply to All". Then I type in the new group of who I want to give it to. But, it also gives me the email addresses of everybody that saw the email beforehand."
IT: "Have you tried selecting "Forward" instead of "Reply to All"? Then you only have to specify the groups you need it to go to?"
This is a TRUE story, I'm really not making this stuff up. However, it shows how quickly we think we need to create another solution when the obvious solution is right in front of us. In this case, the person know how to forward email but had made up his mind that he was doing it the right way but the email reader wasn't working the way he expected. To fix the problem (it surely couldn't have been him, it had to be something else!), unnecessary time could have been spent creating a script.
I wonder if this happens the same way with products. We quickly expect that the products don't work and try to make them do something different as a result. We don't realize that perhaps we just don't understand how the product was designed. Once we do understand that, we may realize that the product is actually working as it should!
Anyways, I couldn't resist passing along this story!
Monday, March 5, 2007
Pay Attention to the Message behind the Manifesto
I have already talked about the Agile Manifesto, but what many people don't realize is that also on the Manifesto web site there are principles behind it that were also defined by the group. I have a tendency to review these occasionally to remind me why the "founders" of Agile had in mind of what they wanted the long term goals to become. Take a look at what they wrote, I put some key phrases in bold to bring highlight to some of the language:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Friday, March 2, 2007
Interview with the Poppendiecks
InfoQ just recently conducted a video interview with the Poppendiecks. If you don't know who they are, here is an introduction:
Lean software gurus Mary and Tom Poppendieck share their years of practical experience, as they speak on the history of Lean thinking, the value of fast delivery and deferred committment, their use of Value Stream Mapping to identify and reduce waste, the importance of identifying and dealing well with cross-organizational and inter-organizational boundaries, and how Lean relates to RUP and Scrum.
They cover a wide variety of topics in this Question and Answer session. Everybody should get something new from it. You can find the video here.
Mary and Tom Poppendieck www.poppendieck.com teach and consult worldwide on Lean principles for software. Their practical, customer-focused approach to software development identifies real business value and enables product teams to realize that value. Mary has managed solutions for both operations and new product development. Tom is an enterprise analyst, architect, and agile process mentor.
Lean software gurus Mary and Tom Poppendieck share their years of practical experience, as they speak on the history of Lean thinking, the value of fast delivery and deferred committment, their use of Value Stream Mapping to identify and reduce waste, the importance of identifying and dealing well with cross-organizational and inter-organizational boundaries, and how Lean relates to RUP and Scrum.
They cover a wide variety of topics in this Question and Answer session. Everybody should get something new from it. You can find the video here.
Thursday, March 1, 2007
What Value should be
A common theme that you will see throughout Agile and Lean is this concept of customer value. The order that you do the work should reflect the highest value to the customer. This really isn't a new idea, I have known over the last 20 years that I need to produce something that the customer wants. However, the problem is that even though I knew that was the right thing to do, I didn't always think about my work in the shoes of the customer. As a developer, I remember thinking that if I put this cool new function in using some cool new technology that the customer would love it. I mean why wouldn't they, I thought. But many times I found that by not checking with the customer I wasted time implementing something they didn't really want or ask for. This resulted in either rework or leaving in functionality that was never or rarely used. Neither of those scenarios are good, because I could be spending my time on things that the customer really wants. If only I had asked them (or somebody that represented them)...
So, with Agile and Lean, this is one of the "prime directives" - to make sure that what you are doing has value to the customer. This is a good thing, a REALLY good thing. You need to have a customer representative always available to the team. Not just when they determine requirements, but through the whole process - design, testing, and especially demos of the working software as it is being developed iteratively. It's all about feedback and checkpoints along the way that you aren't wasting your time. In the end, it translates to functionality the customer will use more often. This translates obviously to happy customers, which translates to good word of mouth, which translates to more customers...well, you see the point.
But since we have adopted Agile (and looking at Lean), there has been a little problem with this. You see, we have over 2500 customers that are using our products. While it is good to know what they want in the product, EVERY customer may have different ideas of what is important to them. So, isn't this customer value? Shouldn't we be doing the things that matter to them? Of course, but there are too many things coming through the pipeline and it's difficult to know which customer request is more important than others. So, what have we done? We prioritize by the size of our customers. After all, they represent a larger percentage of our customer base right? While that's true, it doesn't give the little guy much of a chance to offer good ideas. And, those ideas might be the best thing for all other customers.
So, while sitting in the Lean class this week I realized that we are focusing on only a small part of value - Customers. What we need to focus on is Business Value. What is Business Value? Well, customer value is definitely part of the equation but it also looks at what is good for the overall business. Does this request support the majority of our customers? Does it support our long-term goals? Do we have the capacity (people, skills) to fulfill the request? Does it fit our business model? Does it align with where we are taking our products? Is it something that our company should do? I believe that if we ask those questions we will have a much better idea of how to prioritize requests as well as know which requests we should take on. How do we measure that? Return on Investment (ROI)!
So, with Agile and Lean, this is one of the "prime directives" - to make sure that what you are doing has value to the customer. This is a good thing, a REALLY good thing. You need to have a customer representative always available to the team. Not just when they determine requirements, but through the whole process - design, testing, and especially demos of the working software as it is being developed iteratively. It's all about feedback and checkpoints along the way that you aren't wasting your time. In the end, it translates to functionality the customer will use more often. This translates obviously to happy customers, which translates to good word of mouth, which translates to more customers...well, you see the point.
But since we have adopted Agile (and looking at Lean), there has been a little problem with this. You see, we have over 2500 customers that are using our products. While it is good to know what they want in the product, EVERY customer may have different ideas of what is important to them. So, isn't this customer value? Shouldn't we be doing the things that matter to them? Of course, but there are too many things coming through the pipeline and it's difficult to know which customer request is more important than others. So, what have we done? We prioritize by the size of our customers. After all, they represent a larger percentage of our customer base right? While that's true, it doesn't give the little guy much of a chance to offer good ideas. And, those ideas might be the best thing for all other customers.
So, while sitting in the Lean class this week I realized that we are focusing on only a small part of value - Customers. What we need to focus on is Business Value. What is Business Value? Well, customer value is definitely part of the equation but it also looks at what is good for the overall business. Does this request support the majority of our customers? Does it support our long-term goals? Do we have the capacity (people, skills) to fulfill the request? Does it fit our business model? Does it align with where we are taking our products? Is it something that our company should do? I believe that if we ask those questions we will have a much better idea of how to prioritize requests as well as know which requests we should take on. How do we measure that? Return on Investment (ROI)!
Subscribe to:
Posts (Atom)