I’ve never been a micro-manager, especially not since using agile and Scrum. I could have turned into a micro-manager early in career, except I’ve always been too busy to spend my time checking up on people. But, while I’ve avoiding checking up on teams or people, I’ve never been reluctant to check in with them. I was recently reminded of this by reading an article about the importance of small wins.
While checking up and checking in may seem similar, there are four key things a good ScrumMaster or agile project manager can do to avoid crossing the line into micro-management while still checking in on a team:
1) Be sure the team has the full autonomy to solve whatever problem they’ve been given. A good ScrumMaster ensures the team is given complete autonomy to self-organize and achieve the goal its been given.
2) Don’t just ask team members about their progress; offer them real help. ScrumMasters do this, for example, by protecting the team from outside distractions and removing (or even anticipating) any impediments.
3) Avoid blaming individuals. Things will occasionally go wrong. Assigning blame when that happens will make people feel they are being checked up on rather than just being checked in with.
4) Don’t hoard information. Micromanagers tend to view information as a resource to be retained and only shared when needed. A good ScrumMaster will share anything learned by checking in with others who could benefit from it.
So, stop reading this blog and go check in with your agile team right now. Just don’t check up on them.
I’ve been wondering lately if Scrum is on the verge of getting a new standard meeting–the Backlog Grooming Meeting, which is a meeting an increasing number of teams are doing each sprint to make sure the product backlog is prepared and ready for the start of the next sprint.
To see why a Backlog Grooming Meeting may be a few years away from becoming a Generally Accepted Scrum Practice, or what I call a GASP, let’s revisit the early 2000s.
Back then, Scrum didn’t have a formal Sprint Retrospective Meeting. Prevailing wisdom at the time was, in fact, fairly opposed to such a meeting. The logic was that a good Scrum team should be always on the look out for opportunities to improve; they should not defer opportunities to discuss improvement to the end of a sprint.
That argument was a very good one. However, what was happening on teams was that day-to-day urgencies took precedence and opportunites to improve often went either unnoticed or unacted upon. And so what most teams eventually realized was that of course we should improve any time we notice an opportunity, but at a minimum each team should set aside a dedicated time each sprint for doing so–and thus the retrospective became a standard part of Scrum. This was helped along tremendous by the great book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen.
I’ve had more CSM course attendees recently asking questions about a Backlog Grooming Meeting as though it were a GASP. Many are surprised when I tell them that not every Scrum team has such a meeting each sprint. I still don’t advocate every team conduct a Backlog Grooming Meeting each sprint–as with the early arguments against retrospectives, I’d prefer backlog grooming to happen in a more continuous, as-needed way–but so many teams are successfully using a Backlog Grooming Meeting, arguments against it may be on their last gasps.
Share what you think below. Will a Product Backlog Grooming meeting become so common it becomes a Generally Accepted Scrum Practice (GASP)?
Following the article in the Wall Street Journal on daily standup meetings a few weeks ago, a number of other places have interviewed me abut the topic. I don’t know why they’re asking me, but the interviews have been fun so far. The latest was on the National Public Radio (NPR) Marketplace show on Monday, 20 February 2012. You can listen to the whole show but Sarah Gardner’s interview with me begins at 18:50.
I’m thinking of buying a new car. So I’ve put together a list of cars to consider. Here they are in priority order:
- Bugatti Veyron Super Sports
- Pagani Zonda Clinque Roadster
- Lamborghini Reventon
- McLaren F1
- Koenigsegg CCX
- Porsche Carrera GT
- Aston Martin Vanquish
- Toyota Prius
- Toyota Camry
- Tata Nano
Unfortunately, though, I’m not sure I can afford my top priority car. So let me put some points on each car. I’ll start with the least desirable car and put a 1 on it, a 2 on the next car, etc. That reorders our list so with points on each car we get:
- Tata Nano
- Toyota Camry
- Toyota Prius
- Aston Martin Vanquish
- Porsche Carrera GT
- Koenigsegg CCX
- McLaren F1
- Lamborghini Reventon
- Pagani Zonda Clinque Roadster
- Bugatti Veyron Super Sports
Now I think about my personal spending limits and I can spend between $25-$50k on a car. I’d like to be closer to $25k but a good salesman might get $40-50k out of me. Since the Tata Nano (at one point) goes for about $2500 that means I can afford between 10-20 points.
So, looking at the list again and the points assigned to each car, I think I’m going to buy a Bugatti (10 points), a Pagani (9) and a Tata (1 point). Unfortunately, when I show up at the Bugatti dealer, I am somewhat informed that the Veyron lists for $2,400,000.
What went wrong here?
The problem is that points are not a ranking. When we rank product backlog (or car backlog) items we use ordinal numbers (such as first, second, third). We cannot add ordinal numbers together. We cannot say that the distance between first and second is the same as from second to third. The Bugatti in this example is not ten times the cost of the Tata.
Ranking stories (or cars) like this is worthless. We want story points to instead reflect the relative effort involved. For cars we could put points on as follows:Tato Nano 1 Toyota Camry 12 Toyota Prius 14 Aston Martin Vanquish 102 Porsche Carrera GT 193 Koenigsegg CCX 218 McLaren F1 388 Lamborghini Reventon 640 Pagani Zonda Clinque Roadster 740 Bugatti Veyron Super Sports 960
These points are of course based on the relative costs of these cars. I need to be able to do the math on these estimates that someone would want to do. Someone can afford 20 points on a car–which should they buy? Should I buy this item for 10 points or those other two for 5 points each? You can’t do that when points are assigned via a ranking.
Story points on an agile product backlog represent the effort to implement the backlog item. Since cost on most software projects is made up almost exclusively of labor (rather than buying parts), we can think of a story point estimate on the product backlog as being the cost, as in the car example here.
And, when I look at the relative costs here, I can tell I belong in the Toyota dealership rather than the Bugatti dealership.
Sandy Walsh, a developer at Rackspace who also works on the OpenStack cloud development project, has written a blog post asserting that Iterations and Time-boxing are (Mostly) Useless. While I enjoy Sandy’s thought provoking content, I feel compelled to respond with some alternative points of view, as my company is currently providing Scrum-centric Agile coaching services to Rackspace. I’ve also enjoyed working directly with J.B. Rainsberger, who commented on Sandy’s post, as a Board member of the Agile Alliance, and suggest that JB makes many fine comments. You can also see Glen Campbell’s post as a reply to Sandy here. Given that I like to write, I hope you find a lot of value in this rather long post.
Agile and Code Management
Let’s handle the easiest item that Sandy addresses – code management. Sandy correctly points out that Agile and Kanban stress traditional code management practices and that modern code management tools help enable agility. Yup. Just like we’ve always known that test automation is a good thing, but we’re starting to see a lot more of it because of better test automation frameworks (aka tools).
XP, Agile, and Experience
XP is the Agile method that plays best to highly accomplished, experienced developers. To understand why, we need to understand what a cognitive psychologist means when we say that someone has “experience”. We mean that this person has a deep, thorough, and accurate cognitive library of stereotypical plans (you can think of a cognitive plan as similar to a software pattern) that they can use to efficiently and competently solve complex problems.
Expertise, therefore, is the ability to “know” the “right” way to solve a problem because you’ve solved this or similar problems many times before. It is this notion of “expertise” that cause individual “expert” developers to complain loudly when asked to decompose backlog items into 3hr or less tasks in a Sprint planning meeting - “Dangit – I just know how to get this done – why do I have to task it out?” In reality, experts do know how to get these things done, and task-decomposition can be really painful (this is a well-known problem in knowledge engineering; the greater the expertise, the harder it is for the expert to explicate their cognitive library).
The reality, however, is that most development teams are composed not of superstar experts, but of a mix of people with different skills and experiences. As such, the Sprint planning process of decomposing backlog items into 3hr (my target recommendation) task helps ensure that thorough planning is accomplished (as JB recommends), enables the team to work as a team (because tasks can be done by various individuals within the team), and increases confidence that the team will accomplish their work as a team with measurable progress.
You can find a detailed discussion of cognitive libraries and the interesting effects of different levels of expertise in Chapter 1 of my book “Journey of the Software Professional”. As I said earlier, of all the Agile methods, XP is the method that plays most to experience, and that the greater the experience of the development team, the more likely that they will gravitate towards efficient execution of XP practices.
I’ve coached mature Agile teams who have earned the right to simple decompose tasks without hour-based estimates, because they’ve proven that their tasks are such that reliable progress can be made. This proof is that when they plan for a task to be accomplished within a day… it is. Over time, this becomes a very powerful habit – learning to plan so that more often than note, teams can move tasks from “work-in-progress” to “done” and from “to-do” to “work-in-progress” every day. However, I do believe that this is something a team must earn, and until they’re reliably creating and delivering against small tasks, they should be doing hours based estimates.
I Don’t Want “Command and Control” (Unless I’m Commanding and Controlling)
I find arguments from developers against fine-grained task decomposition very interesting. One hand, most developers dislike being told by management what they should be doing. This aspect of a self-managed team – that the team chooses how tasks are consumed – is one of the single most liberating aspects of Scrum-based Agile. And yet, in the same conversation, these developers often rail against detailed task decomposition because they “know” who is going to do the task.
Let’s get this straight. The Sprint planning process is pretty straightforward: The team decomposes tasks into the work that needs to be done. The team chooses who works on the tasks. If the team chooses to have one person do the bulk of the decomposition of a single user story – then great – do it. If the team chooses to have one person do the bulk – or even all – of the tasks associated with a backlog item – then great.
I can’t put my finger on why this concept appears to challenging to some of the teams I’ve coached.
This is, however, a lot more to this story. If you’re really motivated to create high performing teams, read on.
Team Performance and Shared Transactional Memory
A team that chooses to forego fine-grained task decomposition is also choosing to forego an amazing opportunity to create a higher performance team. I discuss this extensively in chapter 7 of Journey of the Software Professional, so here are some highlights. (See also What’s Collaboration and Some Answers to “What’s Collaboration?”).
I’d like to specifically focus on an important aspect of team performance based on something referred to as a collective mind or a shared transactional memory. Here is how I described it more than 25 years ago – a description I believe is still valid today.
Suppose you are comparing two teams, Team A, and Team B. Team A is obviously more effective than Team B. The question is “Why?” Lots of potential variables come to mind. Team A might have better tools, a better working environment, more experienced developers, and so forth. But what if you could hold all these variables equal? What could now cause Team A to be more effective than Team B?The answer lies in how the members of Team A have molded their collective experience into a sum greater than the parts. Somehow, Team A is more effective when working together than when working apart. But how can this happen?Think about some of your earliest interactions with your colleagues. What did you know about them when you first met? What do you know about them now? As we work together, we learn about each other. We learn Jill is an excellent analyst, Raji is a great designer, and Ruth is a powerful motivator. The team forms a collective mind, in which the interdependent actions of the team create a “a separate transactional memory system, complete with differentiated responsibility for remembering different portions of common experience” [Weick 1993]. More plainly, we not only know Jill is an excellent analyst, we rely on our knowledge of Jill being an excellent analyst, and begin to assign her tasks capitalizing on her skills. We remember the tasks she has been given, and rely on her memory when we need information about those tasks. A collective mind enables the team to become more effective in problem solving precisely because each member of the team can rely on other members to provide experience and skills we do not possess as individuals.Conversely, just because the raw potential of the team exceeds the individual does not mean it will be realized. There are times when a team can perform much worse than any single individual. One way this happens is when teams fail to account for their own poor performance. Instead of working to identify what is wrong and fix it, effort is spent identifying other groups that can “take the blame” [Kahn 1995]. Another way this can happen is through groupthink. Groupthink occurs when each member of the team stops critically examining decisions in order to make them better. Instead, effort is spent finding ways to justify a poor decision [Janis 1971]. Collective mind and groupthink represent two extremes: one optimal and the other to be avoided at all costs.What are the implications of collective mind? First, the potential of each team is unique, initially based on the individual ability of each team member. When harnessed, this can produce incredible performance, as when the Macintosh team created the first Macintosh or when the Chicago Bulls won three NBA championships in a row. Second, individual talents alone do not imply success. A collective mind is based on the collective skills and experience of the team. No matter how good the star, he or she needs a supporting cast. Third, a collective mind can only be formed as the result of interactions among team members. This process takes time. How long did it take the Bulls to win their first NBA championship, even with Michael Jordan leading the team? Fourth, a collective mind is a fragile thing, easily lost and not easily recreated. Did the Bulls immediately win the title when Michael Jordan returned to the team in 1995? Finally, because team members rely on each other for information, skills, experience, and ability, changing the composition of the team can have substantial repercussions.Note: Send me an email if you want the references cited above.
The alert reader will see the implications of Sprint task decomposition in helping form high-performing teams: It helps form the collective mind. And it keeps this mind fresh, because team members can choose to perform different tasks.
Some Thoughts on Estimating
My experience with estimating is that estimating large, poorly specified, inter-dependent backlog items is very hard. That’s different than saying we estimate future things more poorly.That’s why agilists like backlog items that follow Bill Wake’s acronym INVEST. The “S” means that the backlog items are “small enough” to be estimated. More generally, humans are better at estimating smaller things more accurately than larger things, and we’re better at estimating things within our experience base (cognitive library) than outside our experience base. Which is why we lean heavily on the people who own the backlog to create “small” backlog items. Which is also hard, because customers want big chunky innovative things that make your product awesome, but to create these big things in a reliable manner, we need to decompose them into smaller things. Sandy recommends 1-3 days, which is fine, but I suspect that Sandy would agree that Innovation with a capital “I” doesn’t happen in 1-3 days. That’s OK – but it means that we have to have different levels of estimating to serve the needs of the business. I recommend three levels of estimates: shirt sizes, points, and hours. Here is how I like to use them.
Shirt sizes are created by one or two trusted senior technical leaders for roadmap items, “epics”, and backlog items. While these items don’t typically meet requirements of the INVEST acronym, shirt sizes, as non-binding estimates of time become invaluable tools for product managers and product owners to understand the implications of certain business decisions.
Since Sandy references Barry Boehm’s spiral method, I’m guessing that Sandy is also familiar with Wide-Band Delphi as an estimating practice. Points-based estimates are just wide-band delphi, repackaged with a bit of fun.
We use points based estimates as the next level of estimates of the amount of work that the team expects that they need to do to complete all of the backlog items that they business believes is required to release software to customers. It is a way to provide a more accurate schedule estimate than a WAG, because by tracking work-completed-per-unit-of-time, we can create a velocity. Mike Cohn does a good job of explaining this in his many varied writings. And yes, items that are subjected to points-based estimates should indeed follow the INVEST acronym, which is part of the art of Agile Product Management – learning to “split” large, innovative, market-changing roadmap items into collections of small, INVESTable, Sprint-items. Of course, Scrum isn’t new in this regard – task decomposition is a fundamental activity in any project regardless of method.
Wide-Band Delphi has other benefits. It helps teams feel like, well, teams, because they were involved as a team in creating the estimates. It provides an opportunity for significant organizational learning as various team members clarify their understanding of the backlog item being estimated. And it provides real-time opportunities to have critical conversations about the story before work begins.
Lastly, we use hours when planning a Sprint to provide confidence that the specific backlog items undertaken for the Sprint have a high degree of confidence in completing by the end of the sprint. This is tracked in the “burn down”, and is useful for “early warning” during the Sprint. This may not be needed in a Kanban-style model, but I’m in agreement with JB – through tasking of a story helps ensure it is completed effectively.
Of course, we agree on the value of responding to change rather than following a plan. But we still plan. At the roadmap, release, and Sprint.
What About End of Sprint Waste?
Sandy expresses what appears to be grave concern over the potential for “waste” at the end of the Sprint. In nearly a decade of coaching Agile teams, I’ve never seen a team consistently have “waste” at the end of the Sprint. Here’s why. A Scrum team that engages in release planning will have, as Sandy illustrated, created a release plan based on a number of Sprints and the expected number of stories – points – they will complete in each Sprint. Let’s say that in Sprint one the team estimates that they’ll deliver between 25 and 35 points. It is, after all, their first sprint, so they have no historical data on their own performance. Let’s assume the team agrees to tackle 29 points and at the end of Sprint one they complete all 29 points and have time left over.
First, this team should be celebrating. They delivered “Done, Done” work within their estimated velocity. This is outstanding.
Every team I’ve coached will adjust their plan for Sprint two and pull in additional backlog items. So, will the original plan for Sprint two might have been another 29 points, the adjusted plan for Sprint two will have something like 33 points. Note that the team still hasn’t adjusted their estimated range of points – they have no data that suggests they’re off.
This process continues until the team reaches a reasonable number of points that they can consume on a regular basis. If they increase their performance because of thorough planning or just better development, then they’ll gradually raise their range of estimated points – perhaps from 25 to 35 points / Sprint to something like 35 – 45 points / Sprint. That’s a marvelous improvement, and ultimately, increase team velocity is everyone’s job.It won’t result in indefinite waste in every Scrum cycle because the team is adjusting their work based on the reality of what they’re delivering.
And, for the record, I feel that Sandy is (perhaps inadvertently) painting a somewhat optimistic picture of Scrum teams. Most Scrum teams, especially those who are new to Scrum, underestimate how hard it can be to get a backlog item to “Done, Done”. They don’t usually have free work at the end of the Sprint. Instead, they’re hustling to meet their commitments, and usually downgrading the number of points in the next Sprint.
And on those rare occasions when a team does have a bit of extra time in their Sprint I am completely comfortable letting them decide how to spend it. (See also: Entropy Reduction and Sustainable Agile Development).
Predicting the Future – Always A Challenge!
I appreciate that Sandy has a sensitivity to helping provide an estimate of when the team will be finished. He correctly identifies the realistic needs for business to understand this. However, his solution will only really work for certain contexts, and we need other solutions for other contexts.
One context is a Silicon-Valley software startup like The Innovation Games Company. We make a fantastic brand engagement platform called Knowsy. And we often operate more like the Kanban model that Sandy espouses than the typical Scrum multi-sprint release model I usually teach to my enterprise clients. That make sense – we’re not yet driven by market forces and we’re a small, co-located team. We release software when we’re ready. And we have zero complex team coordination issues. So, we release when we’re ready.
Most enterprise / business software, however, doesn’t fit this context. As Sandy points out, there are complex, inter-related dependencies with other teams. And these teams need to move from “How fast can you ship this?” to “When should we ship this to maximize our profit”? Note that the former is a question usually driven by product teams who are unclear of the market events and market rhythms of the market segments they’re serving, while the latter question is driven by product teams who understand when it is most advantageous to ship bits. In these cases, a release plan, which I define as a the expected number of Sprints required to consume the number of required backlog items to create enough business value to motivate the release, is a critical component of the overall product development process.
Release planning is hard work, and I find that teams who have enjoyed the benefits of running a few Sprints and have a sense of “Done, Done” typically do a better job. Of course, that’s not a requirement, because estimating effort using Wide-Band Delphi doesn’t require a team having Sprint experience. It is just nice, and that’s why we try to sequence transition projects by having teams get good at Sprinting before being expected to develop a release plan. Regardless, release planning is a grand tradition in Agile (re-read the Agile Manifesto if you’re not sure).
All of this said, it is important that we, as a global community, continue to experiment with ways to estimate the future. One area that I consider promising, but have not formally explored with any client, is the use of a prediction market. Microsoft, for example, has reported some success with prediction markets (see, for example, this rather dated article from Business Week). In my ideal world, I’d like to compare a prediction market model with the release planning process I advocate to see if there is convergence. In both cases, I suspect that as the items in the release become more INVESTable the accuracy of both the release plan and the prediction market will increase. But maybe I’m wrong. Maybe the key to getting actionable estimates on relatively imprecisely specified work is through a prediction market.
Lastly, I want to recognize that there other approaches to estimating. Function points, for example, is based on mapping new work to a known standard, and is certainly appropriate in certain contexts. However, function points is often too slow for relatively small, fast-moving Agile teams, and, since I’m not qualified to use it, I don’t.
Are You Optimizing for Individual or Organizational Efficiency?
This is not an easy question. Before jumping to any conclusions, I ask you to consider the nature of the organization that is creating the code and the responsibility that this organization has to its respective constituents. Brooks pointed out ages ago in The Mythical Man-Month that a small team is dramatically more productive on a per-person basis than a large team. But you couldn’t create the OS 360 with a 9-person team, and companies like Rackspace can’t create new industries and amazing products like Cloud Servers of Cloud Files without large groups of developers.
So, yes, I’ll readily admit that any process that deals with macro planning and multi-team coordination will introduce a certain degree of process overhead that detracts from “writing code”. All of my clients know that I recommend that they create 2-3 year roadmaps, representations of system architectures, and diagrams of system / team dependencies. All of these are not “writing code” and all of them, to some level, introduce a level of managerial overhead. And while we seek to keep these to a minimum, we do them because the coordination of large groups of people require certain forms of managerial overhead.
I’ll conclude by answering Sandy’s actual questions:
Sandy’s Question: “What do you think? Would your daily development process be better if you didn’t have to break down tasks to super-fine resolution?”
Luke’s Answer: It depends on the nature of the task. If you’re asking me to “go solo” and work alone in tackling a backlog item that is within my cognitive library and one that I’ve proven that I can successfully perform multiple times in the past, then, no, my personal daily development process will not be more efficient with a “super-fine” resolution task decomposition. However, if you’re asking me to tackle a backlog item that is new, or to work with a team that may not have a reasonably similar cognitive library as my own, or honor the idea that a Scrum team chooses which team member(s) will work on tasks, then yes my team will be more efficient with a “super-fine” resolution task decomposition, where super-fine is defined as tasks with a 3hr or less estimate.
Sandy’s Question: “As a manager, could you better estimate ability-to-deliver based on higher-level sentiment vs. tasks completed?”
No. The best way to estimate future ability-to-deliver future work is similarly sized actual work completed by the team doing the work. Teams who undertake serious and thorough wide-band delphi estimation and then rigorously track their work to a consistent standard of “Done, Done” create the best “ability-to-deliver” estimates. (See Jeff Sutherland’s excellent data on such teams).
Sandy, thanks for giving the global community something good to discuss.
The following was in response to Mark Hurst’s recent post How to change the CEO’s mind.
UX rarely has power in an org. Often, we must convince those who make decisions that to do what we recommend is beneficial to the company, their teams, and to them as individuals (not necessarily in that order). It’s a permission game. The more permission we are given, the better we are able to do our jobs.
Sometimes we have champions in the org that recognize our value and what we can deliver. Often there are those who at worst know the UX buzzwords and at best aren’t willing to give UX enough of a priority to be effective. Those are the cases where we don’t have much permission to act and can be frustrated at our lack of impact.
In these cases, a more modest approach may be necessary. Each additional bit of value we deliver and can take some amount of credit for will typically give us a little more confidence and permission until we have earned the trust of the one with the power. That can take time. Sometimes a lot of time.
A key decision as practitioners is whether it is possible to change this person’s perspective and if it can be done in a timeframe we are comfortable with in terms of our own growth and career (and whether there are other options available). I’m not saying quit as soon as you hit a wall with a stakeholder. Recognize that change takes time. Recognize that not everyone will change. Decide whether you have the patience to wear down the rock.
That being said, I agree with Mark. The transformations that stakeholders can have from seeing real users interact with their product can be amazing. However, as many commenters pointed out, you need to have permission to first do the testing and then for the stakeholders to trust you enough that they are willing to change their minds based on the test results in order for it to be effective. This is less about the techniques you employ then it is about your relationship with your stakeholders.
It's a new month, and now there is a new Scrumy feature for Pro users: The Scrumy API. Pretty much anyone who has asked us if we have an API recently has already been directed to that page and has been able to access it, but now we're sharing our secrets with the world.
For the uninitiated, an API is an interface that we give to you in order to access the data that we've stored for you in a convenient way. Essentially, it allows you to write your own programs that interact with your Scrumy projects. If, for example, you wanted a big red button that moves all your unfinished tasks into the 'Done' column, you could build that yourself with a few clever API calls.
The Scrumy API is divided into two separate parts: REST and Webhooks.
The REST API allows you to get data from your projects in XML or JSON form using simple URLs. You can also manipulate your data by POSTing or PUTing data to those URLs. You can read all about it at the REST API documentation page.
Webhooks are very different. A Webhook is a URL for an application that you have running on your own server which receives data from us. This means that any time you create or change a task, for example, we will send a piece of data representing the change on your project to that URL. A simple thing you could do with this would be to send a tweet any time you finish a task. Read more at the Webhooks documentation page. Also, the demo is set up to use webhooks, but it works a bit differently than your projects. The demo will allow you to enter 5 webhooks, but none of them will be active for more than 5 minutes. So, if you just want to see how webhooks work, feel free to use the demo, but unless you want to be a jerk, use an empty slot. Then you have 5 minutes to test your heart out.
So those are the big updates for now. If you find errors while reading the apidocs or feel that you could clarify something, feel free to update the documentation. It's a wiki for a reason. If you have any other questions or comments, feel free to contact us at firstname.lastname@example.org.
I had an interesting conversation with a manager the other day about how to gain more insight into changes that are ongoing in the application one of our pilot Scrum teams is working on. First, what’s the problem? Group A was doing independent regression for a release and uncovered some ”defects’ that were a result of changes in the application by our Scrum team. Truth be told, those ‘defects’ are actually de-commissioned functionality.
Manager: We need to know what’s being changed in the application, we can’t be chasing down defects because of changes we don’t know about.
Me: Agreed. We’ve extended the offer for you to come to our end of iteration demos and until this week we haven’t made any changes in existing code so I agree, with these changes we’ll have to invalidate some of the old regression tests that aren’t needed anymore.
Manager: I don’t have time for that. Is there some type of documentation about the changes?
Me: Yes. We’ve started using javadocs to document the code and our functional information is in Rally. Brief, but explains the functionality well enough. The team members would easily be able to figure out the impact of the changes since they all know the app well enough.
Manager: I can’t ask my team to waste time sorting through Rally to find this information.
Me: We can export a list for you and email it, it’s a 4 or 5 column XLS with a good summary.
Manager: Do you know how much email we get? I can’t agree to that.
Me: Ok, how about you and the members of the other groups who need insight into the changes come to our demos? We do a 15-minute quick overview before digging deep into the stories we completed.
Manager: They can’t do that, we don’t have approval from their managers to go to your demo.
Me: Ok, we do send a summary of what’s being updated when we make our iteration commitment and we send a summary output after the iteration demo, I can include you on those.
Manager: There’s too much to do, I have to worry about this project, that release, aligning this team with that team, I get too much email now, we need a process.
Me: Ok, so how about we just have the people from the other groups attend our demo, we’ll give them the 15-minute overview and send the summary of changes before and after the iteration. If we need to do a more in-depth session, we’re happy to.
Manager: I’ll go talk to the managers to get permission for the other resources to go to the demo.
Me: Great, that should make it easier and really efficient to share information between our Scrum team and the waterfall and regression teams. Thanks!
At the end of the conversation we were right back to where we started. A quick and efficient session to share knowledge with the people who are programming or testing the software. I had continued this conversation with a few folks to get to the real problem and the challenges being faces are typical.
So what’s up with all the excuses? Did we have to fill up the 30 minute time-slot for the meeting to be effective? I decided to dig deeper:
Q1) Why was the initial response that people couldn’t spare 15 minutes every 2 weeks to get visibility?
A1) Because we are too busy.
Q2) Why are we too too busy?
A2) Because regression testing takes 3 weeks.
Q3) Why does regression testing take 3 weeks?
A3) Because our testing is manual.
Q4) Why is our testing manual?
A4) Because that’s how we do it.
Q5) Why do we choose to do it that way?
A5) Because there are too many projects and we don’t have time to do it another way
I’m sure there were a couple more excuses tossed into that first conversation, I started losing count but the underlying problem of having too many projects in progress at a time are causing a whole host of downstream problems.
At this stage, portfolio management isn’t something we can focus on, especially in a large and complex organization. First step is to create visibility to outside teams and trim down the regression suite so there is less waste with manual testing. Our team has already started looking at automating end-to-end regression for happy path scenarios which will also reduce the amount of time spent on manual testing.
It’s a small step, but we need to start somewhere but the message in this post is that things aren’t always as they seem. The initial response is often a gut-reaction based on stress or other factors and it shouldn’t be confused with resistance to improvement or efficiency gain.
One of the simulations I like to facilitate during training sessions is a simple penny flipping exercise learned from Mishkin Berteig to show how the team approach can lead to substantial improvement and productivity gains.
The idea is simple, have the attendees work in a serial process where they have to pass the penny from person to person. The goal is to get the pennies facing heads up in ‘the product environment’ (which is a piece of paper) at the end of the chain. The second part has the same goal, but the teams can accomplish it however they want. I usually repeat the second part a couple of times to prove the meaning behind the exercise. I’ll add a post with the mechanics on this game later.
Anyway, last night my 2 kids and I were playing dominos which always results in a living room disaster since we have a few hundred of the them. 20 minutes for me to set them up, 10 seconds for them to knock them down. When it was time to clean up I simply stated the goal. ”Ok guys, time to put all the dominos away in the clear bin“. Just like a high-performing Scrum team, we started singing the Wonder Pets Teamwork song (what’s gunna work? TEAMWORK!) and each “team member” started cleaning up.
My 4 year old son started picking up the dominos nearest to him, same for me and my 3 year old daughter. The bucket was pretty much centralized between the 3 of us. After we had cleaned up the dominos closet to us, my son immediately took the bin, moved it to the next ‘batch of mess’ and we proceeded to start with whatever dominos were nearest to us. My daughter had walked towards the pile my son started with so she quickly self-adjusted and started on another pile.
I was stunned. The collaboration was completely instinctive and there was very little, if any, discussion. We all knew what the goal was and we all chipped in. Once there were only a handful of dominos left, all 3 of us focused on that so no one was idle until there were less than 3 dominos left.
Sounds silly, I know, but the Agile principles were were much apparent to me during this clean-up session:
- all team members understood the goal
- team members self-organized
- team members adjusted based on work remaining
- team members started with highest priority items (as in, we all started with the pile in front of us)
- we had fun while working! (For those who don’t have kids, trying to convince a 3 and 4 year old to clean-up is not really that easy most of the time!)
I often get complaints in training sessions about the simplicity of the exercise and that moving pennies is different than real-world work. I agree, it is but applying the one-team, shared goal value is more important. Once folks buy into the team system, the rest of the work falls into line much easier.
This is a quick and simple exercise I ended up doing ‘off the cuff’ but based on feedback from the class, had huge value that talked about why the conversation is the most important piece of the user story.
I focus heavily on making the point that the written word is less important and while INVEST shows us there are good ways and bad ways to write stories, the disconnect is always a result of lack of communication.
This exercise takes Mike Cohn’s “entree comes with soup or salad and bread” statement from his User Stories book and allows small groups to write down what they are giving me when I order that in a restaurant.
- whiteboard or flip chart to record the responses
- a few sticky notes or paper for the small teams to write on
- play-food could be optional to make it more fun!
Set the Stage:
Have the group split into small groups of 3, depending on class size. I had 3 groups of 4 in this particular class. As product owner, I want to order the entree with soup or salad and bread but I have to run to another meeting, I expect to get what I ordered by the time I get back. You can leave the room, but I stayed in the room to hear the type of conversation that is happening.
Timebox: 5 minutes (up to you I suppose, I figured that was reasonable)
- ideally you will get at least 2 different orders. In this case, each group gave me 3 different orders which was perfect to demonstrate the value behind the exercise
- immediately I heard conversations like “what did he mean? does he want soup or (salad and bread) or (soup or salad) and bread?”
- didn’t hear conversations like “we can’t do this until we can ask him what he wants to clarify” – all 3 groups just decided to guess and hope for the best
- the conversation is the most important part of the user stories’ 3 C’s.
- focus on the conversation, not the text in the story
- the conversation to clear this scenario up is 1 minute or less as opposed to the effort required to revamp the documentation, then update the story in your tool
- business people and developers MUST communicate daily
I just thought about this as the class was starting so there was zero prep or thinking, just figured it was better than me blabbing on and on about why people should talk to each other! I plan to try this exercise again, the feedback from the group was unanimous. They all ‘got it’ that the point of the user story was the conversation. I start each class with a focus question and this exercise quickly answered about half of the responses. Most were concerned about the story missing details, how can I write better stories for the team etc.
Would love to hear your thoughts!
Agile Coach Camp 2010 is coming the weekend of March 19, 2010 in North Carolina. I’ve heard great things about Coach Camp and this is my first opportunity to attend. You can check out their site here and for those who aren’t familiar with Coach Camp, it’s an Open Space conference focused on peer-to-peer learning and exploration as opposed to the traditional speaker/audience conferences I’m not a huge fan of.
Anywho, onto the position paper: You’ll notice these are high-level points, that’s the point of Coach Camp. The goal is to share experience and gain feedback from the Agile community.
Title: A Recipe for Enterprise Agile Transformation
Background and Challenges:
- large department within large organization
- tall hierarchy, great deal of office politics
- heavily silo’d organization
- complex product portfolio
- mix of full time, contractors, outsourced developers and teams
- limited people with Agile experience in the organization
- no recognized Agile champion
Speaking and Presentation topics I plan to share:
- transitioning focus of functional managers and other roles
- there is much confusion about ‘where does my role fit’?
- breaking down silos between multiple groups
- having to prove you are worthy of being trusted
- demonstrating and sharing success and failures
- portfolio and team organization
- how to structure your teams with the right skills for the project
- techniques for handling ’specialist’ groups
- how these groups interface with teams
- how these groups share information gained from working with multiple teams
- cross-project knowledge sharing (technical or process related)
- getting people together to talk about experiences.
- How PMO and process teams evolve
- more teaching and coach, less command and control
- spreading Agile culture
- making it about the organization, not the coaches
- teaching the organization to think for themselves
The above topics will be accompanied by some fancy diagrams I’m working on for an experience paper and due to the format of Coach Camp, if my paper is accepted and put into the plan, the topics discussed with likely be determined by what my peers want to hear about.
I am still planning on writing and experience paper I had hoped to have finished by now where I can share more details. Interested in your thoughts and experiences!
Ah, good old re-work. The thorn in the side of Scrum teams, the impossible mountain to climb for development teams. Re-work is un-avoidable. When people see working software, they get new ideas and might want some changes. Here are some thoughts for handling re-work based on a few scenarios that popped up at work this week.If We Knew Earlier, We Coulda Did Something About it
Situation: During our iteration demos the team I’m working with found that they had improvements and suggestions now that they could ’step back’ and see their work. Other folks who we invite to the demo would have some small ideas or our Product Owner would have some suggestions that were nit-picky, but nonetheless would be better for the user.
Problem: Waiting too long to get feedback.
Solution: I’m happy the team came to this conclusion themselves in the retrospective. One of the team members posed the question that why don’t we show our product owner immediately when we complete the story and not wait for the demo? Side note: I’ve mentioned this to them a few times, but it was great to see them take a problem and apply the learnings on their own.Splitting the Iteration into Work and Re-work Phases
Scenario: There is too much re-work at the end of the iteration so we are going to take our 1 week iterations and shorten them to 3 days so we have 2 days to do re-work.
Problem: too much WIP and lack of communication between team and product owner. (In this scenario the product owner isn’t available full-time to the team and the proxy he assigned can’t always make a decision). There are a few other things happening here as well. The work this team does is non-software and they rely frequently on interacting with people in other departments. They’ll start something, get blocked and move on to something else therefore creating a great deal of waste.
Solution: The team has been struggling with this for a few iterations, I’m not working with them but did have a chat with their Scrum Master since he felt it was a failure on his part. Not so at all. I told him maybe trying to hammer Scrum into their work-style wasn’t the best thing to do. Perhaps a Kanban system would be more effective for them. We talked about what that meant and they’re not ready for that so instead they’ll try communicating with the product owner more often and help the PO understand he needs to be available for the team to fulfill their commitments.Agile/Waterfall Hybrids is What we Did!
This one came up in a training session I was doing. One of the attendees said mixing waterfall and Agile can work because in his experience there was no way to handle re-work in Agile. The solution to this is similar to the first scenario I discussed at the start of this post.
The root of this problem is not getting feedback early enough or the lack of daily communication between the Product Owner and the Team that is required when using an Agile process. A deeper problem was the apparent separation between programmers and testers on the team he was talking about. I wasn’t able to deep-dive into the scenario since it was in the middle of class but I offered some suggestions about why it might be happening.
All of these examples, in my opinion, are some of the main reasons why companies fail with Agile. They interpret “Agile” to mean flexible and let’s just change the rules to make it work for us. While Scrum is a simple, adaptable framework, the fundamentals shouldn’t be changed to accommodate a broken process. This type of dysfunction can lead to mis-trust between the Team and the business and also cause a rift between programmers and testers as they will start to ‘fall back’ into a waterfall mentality.
It’s important that the Scrum Master or Coach help the teams struggling with this to understand what the real underlying issue is and to work through it.
The Agile Manifesto is the heart of soul of what it means to be Agile and I often refer back to when talking to colleagues and especially with those that are new to Agile. This post was sparked after a great cross-group meeting that happened yesterday where some information was shared between groups that typically wouldn’t have otherwise collaborated.
I had been asked to present a quick talk on Scrum for a couple of new teams that will be starting up soon, followed by a quick overview of these new projects. The output of this session coupled with what I learned at AYE and through the weekly coach round-table I attend with Michael Sahota, Gerry Kirk and Declan Whelan (special thanks to Michael Spayd for his recent ‘guest appearance’!) gave me some inspiration to write this. I hope it is of value to you.
Client Success over Personal Gain: The Coach isn’t the hero. They are there to help the organization. They need to understand the client and contribute to their success, without worry about accolades or personal gain. This includes the coach fulfilling his duties to the best of his abilities instead of holding back to extend the gig. I like to take the approach that my goal is to work myself out of a job as efficiently as possible because the organization needs to be self-sustaining to succeed. Others will argue that “well, I need to make a living” but I knew the risks when I took this path. If I’m any good I’ll find more work.
Guiding over Dictating: Resist the temptation for the ‘my way or the highway’ approach, especially in organizations that have a more controlling culture. Organizations need to learn and they learn the same way a team learns, through experimentation. A coach needs to help guide them to the answer because the people in the organization are best served to find these answers with the help of a coach.
Objectivity over Subjectivity: The coach needs to remain agnostic in order to avoid making emotional decisions. I do get frustrated when my observation is that the client isn’t listening but that just means I’m doing a poor job of communicating. Remain clearly focused and you will serve the client better.
Adaptation over Doing-What-Worked-Last-Time: Ok, so this one is the same as ‘Responding to Change over Following the Plan” however I mean that organizations are unique. What you were successful with at your last gig won’t necessarily translate into success at your current gig. To me, this one is about understanding the organization’s culture so you can frame your approach. Controlling cultures will require a different approach as opposed to collaborative cultures for example.
I firmly believe it’s the responsibility of any coach to make sure the Agile transition is about the client. Deflect focus from being the expert and help the organization understand that Agile is a tool and it’s only as good as how it’s used by the people using it.
I often find that people new to Agile have a tough time understanding that Agile processes are empirical and there really isn’t a one-size-fits-all model that will work for every organization. Scrum, XP, Crystal, Lean and other Agile methods all have their practices that provide guidance and tools but none of them are going to tell you the recipe for success.
This is one of many reasons why hiring an Agile Coach is a good idea. A good Agile Coach will practice what they preach and use these same methods to help with an Agile transformation. If we are talking the talk, it’s probably a good idea to walk the walk. For starters it shows you’re passionate about Agile and it proves you know the tools and how to apply them. It’s also a great opportunity to lead by example.
There is responsibility and “do’s and don’ts” on the part of the coach and the organization to work together towards an Agile transformation. Below are 4 simple steps with some tips that can serve as a guide for how to approach an Agile transformation. Again, there is no one-size-fits-all approach but there are some basic fundamentals and common sense practices I have found useful that I wanted to share.
Understand: How do you know if you need a hammer for the job if you don’t understand the task in front of you?
- understand why the organization wants/needs to adopt Agile practices
- are they concerned about quality?
- is their business in jeopardy and they fundamentally need to change how they operate?
- are they simple tired of the status quo?
- understand the current state of the organization:
- how the organization is structured?
- where is the support for transforming to Agile?
- what’s the skillset like?
- understand that the Agile transformation is about the organization, not you
- understand that an Agile transformation is more about a culture change than an adoption of processes and tools
- understand that Agile is not a quick fix
- understand the an Agile transformation is costly and time-consuming
- understand that ALL levels of the organization need to be involved
- understand that you will not like some of the answers you get from your coach
Educate: This is important. I find that often people just want the answer. A good coach needs to educate the organization so they can apply that knowledge instead of giving them all the answers.
- teach the 4 values
- teach the 12 principles
- conduct workshops that help the organization understand the meaning behind the values and principles
- make it fun
- Educate them on the use of the tools (both thinking and software tools) you plan to use based on your understanding obtained in step 1
- be open to learning, don’t dismiss the education because “it won’t work here“
- reject the status quo,”look around, it doesn’t need to be this way” – Gerry Weinberg
- challenge and question the education, don’t simply accept everything the coach teaches, challenge those teachings to make them work in your environment.
Execute: Now the hard part. Agile is easy, implementing Agile is very difficult.
- start simple, you should understand how much of a shock the transformation will be, a simple approach may be best
- the organization will not always listen to you. You will serve the organization better if you can remain positive and objective
- collaborate with the team(s) and/or organization instead of giving them all the answers
- learn to ask powerful questions to help them relate the 4 values and principles to daily work
- refer back to the values and principles often, this helps drive the organization to think and apply these values and principles
- start internal user groups, blogs, wikis, get collaboration and discussion happening, spread Agile culture
- remain optimistic, you will be frustrated at times but stick with it
- “embrace uncertainty ” – Jeff Patton
- expect to experience failure, but remember to learn from it
- it might sound crazy, but it just might work. Give it a shot.
Reflect: Use retrospectives extensively, and not just with the team(s). Retrospectives will help the teams with daily ‘in the trenches‘ work and they will help management and executives inspect and adapt on their transformation plan.
- this is a tough one, but be honest with yourself. Are you the right coach for this organization? Do you need help?
- based on organization feedback, add new tools and practices as necessary to support these new learning opportunities
- help the organization learn how to improve in small increments
- try not to get overwhelmed, Agile tends to expose problems very quickly – use reflection to make small, incremental improvements and try to avoid the big-bang solution approach
- be honest with yourself, don’t ignore the problems that surface, attack them
Rinse and repeat often. These 4 steps are cyclical. Reflection leads to a greater understanding which leads to new learning opportunities that will likely require different tactics during execution.
What I really enjoy about being part of the Agile community is open communication and willingness my colleagues have to learning and self-improvement.
I’ve been fortunate enough to interact with some wonderfully brilliant people and a keen observation I’ve taken away is how these folks give feedback to fellow colleagues. The flip side is that when it comes to a manager/employee relationship, very few managers I’ve worked with have this unique skill. I’m quite sure there are some great books on how to give effective feedback (actually, please add some to the comments…I’d love to read some) but I’ve been on the receiving side of enough generic “great job!” comments to know what people truly find appreciative when receiving recognition.
While praise has it’s place, there is no substitute to providing concrete examples of WHY you are appreciative of someone else’s efforts. When I give feedback to team members, employees or direct superiors I make sure to provide them with specific examples of why I appreciate them. A recent example was feedback I gave to a co-worker who is not part of the team I’m working with. This person provided support to our team and also willingly participated in a couple of estimation and planning sessions because the team needed his help. I made sure to state my appreciation that, although he wasn’t part of the team, the team experienced success because of his help at key points in project.
Another side effect of being specific is that your feedback will be more honest and the receiver will be more appreciative because they will know you aren’t just blowing smoke.
Recently I had a brief messenger chat with a former co-worker that they determined they were actually using Scrum-ban instead of Kanban. The timing of this chat coincided when I seemed to be coming across a multitude of discussions about what is/is not in Scrum, what is/is not Kanban and so on.
My initial response was “is what you are doing working?“. Her response was, “yes“.
My response, of course, then was “so why does it matter?”
I do understand the desire to have these processes defined but I’ve never much been a fan of labeling. Being “Agile” isn’t about using Scrum, Kanban, Lean or any other tool/process, it’s about being dedicated to empirical processes that work within the context. I also understand the dangers of ”Agile” being tarnished by misused practices but by and large solving problems and rejecting the status quo are what really matters at the end of the day.
As an example, a few months ago a team member who was recently kicked off the team BY the team decided it was worth his time to prove a point by finding a page in Ken Schwaber’s book that mentions it’s not a rule for the team to stand-up at the daily scrum. My reply was pretty simple in the sense that I never said it was a rule. I explained to the team why it’s a good idea to stand-up and the team decided they wanted to sit, so they now sit. (results of our daily ’sitdown’ here).
Is sitting at the stand-up a Scrum smell? Probably. I don’t care though. The team gets more value out of sitting.
Before I knew what “Agile” was, common sense would dictate that if something isn’t working, find a better way of doing it by trying something new. I believe that’s much more valuable than worrying about what label you put on it.
I’ve been compiling notes over the years with thoughts and ideas about how I could contribute to the Agile community and try to give back just a small slice compared to what I’ve taken from it.
I decided recently to write a white-paper that describes the experience of the success of a pilot Agile team within a large enterprise organization. What I hope to accomplish by writing this are:
- show that we are “breaking” some of the rules, but are experiencing success
- show the challenges large organizations have adopting Agile
- show the mistakes I made, the ramifications and how we forged ahead
- show that motivation is the most important factor in Agile adoption
How I’m going to structure the white-paper:
- Introduction: who I am, context around why I took the approach I did and context around the organization. The company name, projects and people names will be fictitious but the tactics, results and experiences will be real.
- Iteration by iteration: Starting at iteration zero and moving through our 6 iterations for 1 release I’ll show what our iterations looked like, what activities we did, how we co-ordinated with other groups, team frustrations and successes.
- Summary of what we learned: How the team felt moving from old status quo to new status quo and why they would never go back to “the old way”. This will also include what the team is planning to do for the next release in an attempt to show that despite the success, they recognize they are “not done” implementing Agile and want to get better.
- Reflection: What I learned, what I would differently next time.
- When will it be done? End of December
- How many pages? 10 pages tops, I would like to keep it concise
This is my first white-paper, I’m excited and nervous all at the same time, but this is taking me out of my comfort zone and it is quite challenging. I welcome your input and feedback regarding what you would hope to get from reading this white-paper when it’s finished.
One of my favourite scenes from Tombstone is when Ike Clanton says to Wyatt Earp, “Listen, Mr. Kansas Law Dog. Law don’t go around here. Savvy?” After Wyatt replies that he’s retired, Ike reiterates “Yeah, that’s good, Mr. Law Dog, ’cause law don’t go around here.”
A common theme that has been emerging from the classes I’ve been delivering and conversations I’ve been having are along the lines of “wow, we need to change our culture” or “agile won’t work here because … <insert excuse>“ There seems to be a clear delineation between these 2 camps.
I blogged previously about the importance culture has with an Agile transformation and I make sure that I convey that to anyone I talk to that is new to Agile.
The first statement I usually use to combat this fear, uncertainty and doubt is the fact that there always must be a reason to transform to Agile. Companies aren’t switching for the sake of being cool and hip, well if they are they have bigger problems, but instead they are switching because fundamentally, the way they are working is broken.
Transforming to Agile requires a deep organizational commitment and a fundamental shift in how companies operate and how departments and people interact with each other.
So underneath the skepticism and FUD, what’s the REAL problem? What are people afraid of? Here’s a brief summary of the top 3 excuses for why Agile don’t go ’round here:
1) We can’t have a SINGLE product owner, we need multi-level signoff and too many people are “the go to guy”
2) Agile won’t work here, everybody works on multiple projects at the same time.
3) Management tells us we HAVE TO launch with all these features on this date.
Hmm. So what do we do? Where’s the Agile checklist that allows us to fix these problems? I’ve seen Scrum teams absolutely banging their heads against a wall trying to figure out why their fixed-date, fixed-scope projects either don’t make it or have terrible quality. In this cas,e the ‘rapid de-scoping phase‘ happens in order to make the date but in that instance the damage is already done. The teams inability to say no has rendered their yes useless, mis-trust ensues and the cycle repeats itself.
I’ve had this post brewing for a few weeks and decided to post it after our pilot team’s recent success and after reading Gil Broza’s great post entitled “so you think you’re Agile?”
While our topics do differ, the underlying tone is the same. Organizations needs to understand what being Agile is. They need to look to the manifesto, not to the Nokia Scrum test or a checklist. They need to un-learn what has been instilled through so many years of the command and control approach.
AYE helped me change my approach from saying “here’s what you’re doing wrong and here’s the right things to do” to “what are you concerned about? what are your challenges? how can the knowledge and tools I have solve your problems”
Lately that approach is working much better and I find people who want help are more likely to accept help.
I attended the Rally webinar about Keys to Successful Release Planning and heard a great comment from the presenter:
“Focus on delivering software, not the plan.”
Think about that for a minute, it’s ok, I’ll wait.
<insert jeopardy music here>
One of the myths of Agile is that Agile teams don’t plan. Agile teams focus on ‘planning‘, not ‘the plan‘, there’s a difference. Let’s face it, the software development industry moves quickly and for the lack of a better phrase it would just be completely nuts to plan out exactly what we will deliver for all of next year. Sure we’ll have a loose plan for what we want to deliver based on what the company strategy is, but are we going to follow that plan into the ground or adjust to new information? Remember, the Manifesto says we value responding to change over following a plan.
So what’s good about a plan? Everybody loves a plan. Plans are what keep people accountable, plans are what make us comfortable, plans help us feel secure. Once you have a plan, you have set expectations.
So what’s not-so-good about a plan? Once you have a plan, change is difficult due to the perceived chaos change introduces. Once expectations are set, traditionally changes aren’t effectively communicated to all those who should know about it. Plans can be used to place blame when things don’t go according to the plan.
At the end of the day we are delivering software, not a plan. In the end when plans change and chaos ensues, the issue isn’t the plan, it’s communication.
Case in point, in our iteration 6 demo one of our stakeholders asked “I thought you were doing XYZ?” Was it the stakeholders fault? Nope. Was it the outdated roadmap the entire company was looking at? Nope, ok, maybe partially. It was a communication problem.
We had failed to effectively communicate to all of our stakeholders the change to the plan. Sure this change happened 3 months ago and sure this particular stakeholder hadn’t come to any previous demo but once this stakeholder had the plan in his hands 3 months ago, his expectation was come hell or high water, we will deliver the plan.
This creates a vicious cycle, especially in organizations that lack trust. If the team doesn’t deliver the plan, the business instinctively responds with more process and more control. Obviously the team can’t be trusted if they can’t deliver on this simple plan we agreed to right? People, especially teams, become deflated, morale sinks and people co-operate less for the fear of the ramifications of the decision to change the plan. Another nasty side-effect is the battles about scope-creep. We become so focused on arguing about what’s in-scope and what’s out-of-scope we lose sight of the fact we’re delivering software.
So how do we get out of this oscillating cycle? First of all, communicate better. Help the business, or folks having difficulties adjusting to Agile, understand why Agile teams plan the way they do. Listen to their concerns about why they want a committed roadmap for the next 3 years. People are often resistant to change but it’s important to not confuse their response with resistance. There is always an underlying reason for why people respond the way they do, keep the communication open and move forward. Of course you won’t always agree, but listening to others concerns is a great place to start.