Subscribe
Posted on September 30th, 2009
Roy Osherove has just posted a guest post from me on Team Leadership called Leading Through Learning: The Responsibilities of a Team Leader on his new blog about Team Leadership called Five Whys. Thanks for the opportunity to post Roy!
Posted on September 23rd, 2009
Damon Poole just did a post on the Top Ten Things Programmers Hate About Agile. But it’s not just programmers who dislike agile methods. I’ve come across many managers who feel many of the same things that are on Damon’s list. So without further ado, the top ten things management hates about agile:
#10 Agile is Snake Oil sold by Snake Oil Salespeople
Damon refers to Snake Oil salesman who pollute the name of agile with insane rules, crazy methodologies, and generally things that don’t focus on the value. On the flip side, managers see agile as an excuse for Jerry and I to pair on reading Slashdot, cutting our productivity in half. Suddenly documentation isn’t allowed, coding standards are rejected, and the team dissolves into chaos – all under the name of “Agile”. Snake Oil indeed.
#9 Agile Has Too Much Jargon
Imagine you are a manager who has been dutifully reporting your team’s status to upper management using Gantt charts. They know it’s a lie, you know it’s a lie, but the pretty boxes line up to the pretty date at the end, and it looks like stuff has been filled in. All of a sudden I’m supposed to report to an executive team with “burndown charts” measured in “Graham Cracker Cookies” which show that we’ll miss our date – by about two years. And why the heck are my developers testing? At least, I think that’s what they are saying. Something about TDD. Or BDD? Maybe it was ATDD. Or FDD. No, I saw a book on DDD on one of their desks….
#8 Agile Means The End of Control
What’s a manager to do when the boxes on the Gantt chart don’t line up? Hold a retrospective! And by retrospective, I mean calling the team to an emergency meeting, scowling at them and reflecting on what they’ve done by asking, “What the hell is wrong with you all?” And it works – they all scramble like mad men, working overtime, pushing the bits, and making the boxes line up. And now you want to tell me that they are supposed to “self-organize” and “select their own work” and “know what’s best for them”? Please. They’d be nowhere without me!
#7 The Developers Just Want Me to Have an Ulcer
Sure, it seems innocent enough, this “onsite customer” crud. Next they’ll be wanting to sit in on the executive planning groups, offering “feedback”, and then wanting to just talk to anyone! The other groups are far too busy to let them start changing this organization like that. It is *vital* they fill out the proper request form so we can track this! (Although track it why is never said…)
#6 The Agile Consultant Will be A Pain in The Neck
So, you want me to pay $20k for some agile “consultant” to come in and tell my team, “Change your organization or change your organization” and then tell me that *I* need to be prepared and have these stories broken down? That’s not my job! I’m the manager, dang it! I guess I’m doing all this work so they can just go off and play World of Watercraft or whatever that is.
#5 Pair Programming!
Oh! Yeah! Play World of WaterCraft in pairs, so that we take twice as long to get half as much stuff done. I mean, the corporate standard won’t let us tear down these cubicles. Working at pair stations – I know they’ll hate it. They may think they won’t, but I know they will, so best to nip that sucker in the bud.
#4 Stand Up Meetings, Planning Games, It’s Meeting Hell!
At least they are sensible enough to put in a “Standup meeting” so I can find out what this team of lackeys is doing. But what’s with this other stuff? Scrum of Scrums? Planning Games? Break down the tasks right there? How are we supposed to get any work done if we are spending 4 hours every two weeks going through a “backlog”? Code, Code Monkey, Code!
#3 Drive-by Agile Transition
I know this is just a fad. Like that 4GL stuff. And wasn’t VB supposed to make everything better? They just think they’ll do this, then it will blow over like everything else. Why waste all that money?
#2 Just Whiners Asking For Stuff
I don’t get this. They all have a 17″ flat panel monitor, and a mid-grade development machine. Now, because of “Agile” they want two monitors, two keyboards, a build machine, some continuous integration thing, some “refactoring” tool, conferences, trainings – money! I see their little ruse. Besides, I know that if they get this, they are just going to jump ship. It’s never enough for those whiners.
#1 Do Less With More
This agile thing is just a chance for them to make me look stupid. Like I’m going to go to our management and tell them that, “Yes Sir, we’ve been working in pairs! And now we know we are going to be 2 years late!”. I don’t get why they can’t see the math. 2 Developers + 2 Computers = 2*Productivity. 2 Developers + 1 Computer = 1*Productivity. Half. I’m throwing away half my money. Just to me told that our chart says that we aren’t working fast enough. If we’d quit focusing on these “fads” and just work faster, maybe we could actually ship something for a change.
Of course I don’t buy into that. Transitioning to agile methods *is* hard, and absolutely takes a commitment on both the team and the management. And it works best when there can be open, honest discussions about what both the team and management need. It’s unfortunate so many developers are in situations which require them to have to resort to sneaky tactics just to try something new.
The real snake oil is the years of management advice which says that top-down management is the best thing since Gantt charts. That the manager is the manager because she knows best, and, by definition, the team can’t. It’s time to stop focusing on these pretty little charts and asking hard questions. What value do we offer? How can we deliver that value as rapidly as possible? What will help our customers, and how can we reach out to them?
And, in the meantime, work to understand what your management needs, and how you can continue to provide that to them. And if they just don’t want to work with you, then either do it anyway, or find some place that will.
Posted on September 21st, 2009
<< Retrospective After Every Sprint | Series Home | Clearly defined Product Owner / PO has a product backlog >>
The core concept behind timeboxed iterations is that, every sprint, the team delivers running, tested features. So every two weeks, the team gets together and should be able to demo the features they built to the product owner and customers. And in a highly effective environment, the product owner could say, “That’s perfect! Let’s ship that to production!”
And it would seem that if you are doing your iterations, and keeping up with your Sprint Backlog that committing to deliver the feature by the end should be easy for a team to accomplish. After all, it’s not asking a miracle of a team to show what they did, is it?
To understand, let’s look at the context of a large software company that delivers a boxed product. In order to deliver the feature, it of course has to be completed (both development and testing). It also has to be verified that it meets the business needs. And then the real fun kicks in – it has to be added to the production build, the documentation has to be created, the labels have to be localized (exposing potential bugs) and a whole host of other issues might come into play (regulatory approval, 501.3c compliance testing, etc).
So, if we need to do all that to deliver our software, how can we possible demo that we are going to deliver every sprint?
Magic 8-ball, how do we deliver?
In fact, it’s a common question. In a recent experience report, Chuck Maples, the Senior VP of R&D for Borland, admitted the difficulty and struggle of delivering every sprint:
To incorporate performance, scalability and integration testing, we would have to adapt our Scrum practices…This enterprise testing runs one sprint behind and we have a hardening sprint before each release.
It seems reasonable, doesn’t it? Delivering everything necessary to ship the software just doesn’t fit into our iterations, and we don’t want to extend them, so we just have a “hardening” sprint or similar fancy name with which we can get the real final preparations done.
But instead, what we’ve uncovered is a limitation of our process. We’re trying to shoehorn our stories into a process that doesn’t fit. So what can we do?
Change our process, or change our process?
The first thing we need to ask is can we do things in parallel to enable us to ship during the sprint. For example, can our language translation happen in parallel as we are developing? Or can we do a little more design up front to submit the applications for approval earlier? Perhaps we can employ automation to do single-click compliance testing, which we can even employ into our nightly builds.
Of course, anyone who has done significant localization efforts, or dealt with compliance testing knows that it is never as easy as that. Compliance auditors are often very picky about seeing things after they’ve been built. Localization companies are often quite expensive, so unless you have the people on staff, doing things on a week-by-week basis might be cost prohibitive.
To enable this, we should focus on what we’re trying to do. If we can’t ship the story, what is the point of finishing during the sprint? Why don’t we instead focus on what our real goal is – delivering working software. And if we view it from that perspective, then we can work on uncovering ways to work effectively within the parameters we have.
To do that, we start measuring the cycle time of our stories from concept to completion. We might find that when we batch the stories into groups of four to the localization company, they are able to work faster overall then trying to keep up every week or two weeks.
We might also discover that our bottlenecks in between “done” and “shipped” can be resolved by simply doing a small amount of additional work during the completion of the story.
Start with your organization
But before you go about tweaking the process, you have to be able to look at the overall workflow of what it takes to deliver the software. This means using tools like Value Stream Mapping to uncover what the true process is that your team and organization must follow.
It is this discovery, this research, which gives you a solid base to begin discovering how to work more effectively, ship more effectively, and most important, deliver solid running, tested features to your product owners and customers.
Posted on September 10th, 2009
When you think about the hardest part of Scrum, it isn’t the daily stand-ups. Nor the sprint backlog. Not even the demos at the end. The hardest part – and the oft missed part – is “Inspect and Adapt”. Inspecting and Adapting is at the heart of Jurgen’s ScrumBut post. One tool that teams have for this inspection is retrospectives. Not that this is new – there are lots of tools and names similar efforts go by – After Action Review/Report, Hotwash, and the ever popular, “What the hell is wrong with you people?”
To help counter this, Henrik’s Scrum Checklist helpfully includes three subelements to think about for retrospectives:
- Results in Concrete improvement proposals
- Some proposals actually get implemented
- Whole team and PO participates
This also can be tied back to developing SMART results – Specific, Measurable, Attainable, Relevant and Time-bound. And a sixth element – assignable. Someone should take responsibility for implementing or leading the implementation of the solution – and that person shouldn’t be the manager or ScrumMaster.
But is the end of a sprint the only time we can learn from what has happened? Of course not. In fact, we often laud performance review processes for that reason – they aren’t done until the end of the reporting period, and by that point the learning opportunities may have already been lost. Obviously with shorter iterations the mean time to inspection is lower, but it doesn’t mean we can’t become more lean in our approaches to introspection.
Short, yet oh so sweet
The first thing is to try having them every week if your iteration length is greater than a week. You may have to change the format up some, but the shorter cycle times may allow things to be caught much earlier. Like standups, you can try them at the end of the week, or kick off the week with a retrospective. Or, if things are being tied too heavily, put it in the middle. Adjust and tweak to find what works well for you.
One of the more interesting approaches I heard was from someone at KaizenConf last year. They don’t have scheduled retrospectives. What they do is have a spot on their big, visible wall for items that need to be brought up to the team. When it hits a certain limit (1 or 2 usually) they have a retrospective – on the spot. I like that because if people aren’t feeling comfortable calling something out, they can still post it on the wall, and effect the discussion through that means.
Out of sight, out of mind
Yet, even with all of these, I still find it important to have slightly more formal retrospectives on a regular basis with teams. After all, part of the exercise of retrospectives is discovering something that everyone only had a small piece of. And these little pieces can grow and become infected if left completely unchecked.
But yet, even with all of the acknowledged benefits, teams end up not checking this item on the list. Why is that?
- Haven’t cleared the 5 dysfunctions hurdle – Retrospectives require a high level of trust and a culture of openness. For many teams, that just isn’t the case.
- You have a poor facilitator – Effective retrospectives require a strong facilitator. There are lots of antipatterns when it comes to facilitation, and any of us who have ever been in that role can probably relate to one of the antipatterns on that list.
- The team isn’t empowered to make the necessary changes – This can be heartbreaking when the team identifies the very things keeping them from doing a great job – and can’t fix it. In some ways it’s horrendous – they now very much understand what is causing them pain, and know the fix, but can’t apply it
Luckily there are steps. Esther Derby and Diana Larsen have written a great book called Agile Retrospectives which covers a variety of games and skills one can use for holding effective retrospectives.
It’s still smelly
Perhaps the most interesting argument against scheduled retrospectives is on Doc List’s blog post Are retrospectives an antipattern?. In one of the comments, Scott Bellware says:
Scheduled retrospectives are a strong indicator that a team’s management isn’t sufficiently perceptive enough to know exactly when actions like facilitation, drawing out information, deciding how to move forward are needed based on observable phenomena.
And there’s the crux. For high-performing teams, who are adept at inspecting and adapting, modifying retrospectives to be part of a larger value stream becomes second nature, especially when they have a management team highly tuned into the team. But without that, teams need the ability to build those skills in inspecting and adapting, and thus scheduling retrospectives is important.
So if you are a team who is struggling with your retrospectives and want to modify them, ask yourself if you could put a place on your wall for post-its, and then hold meetings as needed. If so, then tweak away. If not, reach out and find someone who can help you facilitate your retrospectives. And begin to build the insights you need to move away from schedules and rigor towards a culture of learning, insight and reflection.
Posted on September 10th, 2009
Ah, the Sprint Backlog. While not quite as visible as the Daily Scrum, the Sprint Backlog makes up the core trifecta of Scrum. And what developer wouldn’t love it? Every two weeks (or four weeks, or whatever iteration length you have) we’ll get together with the product owner. They’ll tell us what is most important, we’ll tell them what we can get done, and we’ll add that to a list. During the iteration that list is all we know as a development team, so no more of this, “I have to have you work on this other thing now!” business.
To a team working in utter chaos, it sounds like the perfect club to wield against a management unit that can’t make up their mind. “Sorry, we’re doing Scrum, and it says you have to leave us alone over the next two weeks.” What they don’t realize is that something that is a weapon can be used by both sides – and when the team doesn’t finish all of the stories they signed up for, management will use that same club against them. But if we look closer at why we have the Sprint Backlog, and why we have to have the Planning Meetings, we can understand better when we can tweak them to fit our needs.
In traditional software project management, the question is, “Can you all get this stuff done in this amount of time?” Because developers are a) optimistic and b) really bad at guessing, the standard answer will be “Absolutely!”. And because management and/or the customers don’t know what they want there will inevitably be a point when everyone realizes they aren’t going to make it, leading to what is known as a Death March.
But the goal with Scrum is instead to say, “Here is how much work we can get done in a timeboxed period. Let’s deliver the most value we can in that time.” So the sprint planning games become the place where the stories are reestimated, reprioritized, and signed up for to create the Sprint Backlog. And because we know the approximate velocity of the team, the release planning becomes a matter of looking at the story estimates, looking at the velocity, and then adding up stories until the time we want to release.
(In theory, of course. One of the better practices I saw with this was to have all of the stories estimated for the release, then add two cards that were each 10% of the total value – one for changes, and one for refactoring or other technical debt. That team generally hit within a week of their estimated date on 6-month projects)
Consistency is the secret sauce
Inherent in developing the Sprint Backlog is that the team can consistently deliver the same velocity iteration after iteration. Using a technique known as Yesterday’s Weather, teams can do a pretty good job of signing up and delivering the stories during the planning meeting.
The interesting thing is that the onus of this process is the consistency of the development teams. While that may make good fodder for mathematical calculations and modeling of release planning, it isn’t always the best for the developers. If we’ve signed up for two stories – one a “4″ and one a “2″, then all of a sudden we find ourselves having to do some planning to make sure that we break these down enough to get them finished. In other words, the stories don’t naturally flow through the team.
But what if they did? What if the consistency wasn’t in the teams, but in the stories themselves?
“Look honey, a real, live Business Analyst!”
If we begin to look at the flow of items through the system known as our development process, we see something interesting. In this chart, we see that even though the story sizes don’t appear to have too much variability, the number of actual hours to complete each one varies wildly. What we really want to do is setup the backlog in a way that smoothes these bumps to reduce the variability in the tasks.
To do that, you begin by throwing away estimates. Instead, your card is your estimate. So if it is written on an index card, it should be the same approximate size as the other index cards. Let’s say a story on an index card only goes on there if the team knows they can finish it in two days. If the product backlog has items that are bigger, then you have a whole group known as business analysts who can evaluate, research and find out just how to break that into smaller items.
When this variability is reduced, then the question is no longer, “Here’s how much we can do in two weeks. Fill us up”. It simply becomes a matter of, “Ok, we’re done! What’s the next prioritized story?” As that begins to happen, the need for a “sprint backlog” begins to go away – the sprint backlog is simply, “What’s next?”
Sounds great, Bob! What else do our contestants get?
There’s an important point here. To get to this, you have to be at a maturity level to allow for several things:
- Recognition of flow through the system – You’ve taken the time to do value stream maps to figure out where the bottlenecks are.
- Invested customers – You have customers and business folk who are willing to work with you to get that level of detail
- Strong definition of done, done – because the consistency comes out of small stories, there is no room for “mini-waterfall” iterations. The team has to be very good at delivering running, tested features
Without these things, then the Sprint Planning Meetings and Sprint Backlog serve a very important goal – to stabilize and checkpoint the development process. So as you begin modifying the planning game and the backlog ask yourself – are we modifying this because we’ve analyzed the flow of our system and found that we need a different optimization stream? Or is it simply because your team can’t even meet two or four week commitments?
Posted on September 9th, 2009
The most visible – and often most abused – part of Scrum is the Daily Scrum, also known as the “Stand-Up”. In this meeting, the whole team meets with the participants answering three questions: What did I do yesterday? What am I doing today? What is blocking me? The “Stand-Up” part comes from the notion that this should be a rapid meeting, and standing up encourages the team not to get comfortable and drone on and on.
Yet despite all of the guidance that this is a meeting for the team and by team, and even with articles such as the “It’s Not Just Standing Up” article by Jason Yip, stand-ups tend to either be another status meeting for everyone to tell the boss what is going on, or worse, boring, repetitive process following.
In Henrik’s Scrum Checklist he identifies an especially important subarea to judge the effectiveness of a stand-up: “Problems and impediments are surfaced.” After all, Scrum is about being effective as a team, and the vital part of being effective is finding out where you aren’t.
This dysfunction is just right
Last year, J.B. Rainsberger said something that really struck home with me. The most widely adopted practice in agile – the stand-up – is the one that requires the most dysfunctions on a team to be solved. In fact, to be effective, a team has to overcome the following items from the Five Dysfunctions model:
- Absence of Trust
- Fear of Conflict
- Avoidance of Accountability
And really, “Lack of Commitment” and “Inattention to Results” – the other dysfunctions from the list – aren’t that far behind. Yet, some teams are able to see a tremendous impact using daily stand-ups. And others find themselves equally effective without them. How do you know when you can get rid of the daily stand-up?
The answer to this lies in the very model we’ve already explored. Teams which feel comfortable being vulnerable to the other members, yet can engage in productive conflict. Teams who hold each other accountable, who focus on collective successes and failures while allowing individual attributes to shine. Teams that stick to what they commit to, but know when to back away.
If your team is doing this, you likely already know intimately what each member is doing, and surprises very rarely come out of the stand-ups. There may be some other aspects out of stand-ups (for example, mini-retrospectives or reflection), however, we’ll be covering some of that in the later article on “Retrospective after every sprint”.
We put the “fun” in dysfunctional
There are, however, some antipatterns when you should keep doing a stand-up. The first, and most obvious, is if the team model described above doesn’t fit your team. But the second is around scaling and colocation. For a tight-knit, colocated team, the daily ebb and flow becomes very natural, and rigid checkpoints may give way into more natural ones (perhaps the teams eat lunch together every day). But as your team scales (3 or more teams working on the same project or product, offshore teams, remote members), that heartbeat of the stand-up will help to synchronize the members, and expose architectural and structural dissonance that might not be discovered until later on.
Another reason you may want to keep a scheduled stand-up time is so the PO or others can join in. This does not mean that you have to mindlessly go through a routine every day – only that the team has a small amount of time set aside for openings.
But time, or the presence of the stand-up, is not the only antipattern. As a team member, watch the circle as it goes around, and think about the subitem Henrik mentions in his checklist. Do you see impediments being raised? Are people engaged? Can one person repeat what the last person said? Do you see them talking to other team members, or just focused on the “leader”?
If so, then find out why. Are the wrong people attending the stand-ups? Do problems that occur actually get surfaced? Do the stand-ups need to become more team-based (if they’ve scaled up)?
So, if you are thinking about dropping your daily stand-ups, or dropping them back to a “couple of times a week” ask yourself – are we truly being effective? Or just scared by what happens when we begin opening up to the team – and challenging each other to be the best we can be?
Posted on September 7th, 2009
<< Timeboxed Iterations | Series Home | Daily Scrum >>
One of the realities of many corporate environments is that you work with a group of people called a “team” but a variety of factors prevent you from actually sitting together. At Alistair Cockburn’s keynote presentation (PPT) at Agile 2009, he showed an interesting slide about the costs of a team not being colocated.
Colocation (and it’s more effective twin, pair programming) aren’t actually Scrum practices per se. Pair Programming is an Extreme Programming practice, and Jeff Sutherland has written several articles on working as a distributed team.
But colocation is a vital practice, so how can you know when it is OK not to be colocated and not doing pair programming?
I miss you already
Since most teams end up forced into non-colocated situations, let’s talk about the organizational maturity necessary to work effectively as a distributed team. When a team is not physically in the same office, there are several important things you lose:
- Facial and Body Cues
- HIgh impact communication
- Incidental conversation
- Low impact help
- Instant reflection
Let’s start with a non-colocated team. Let’s say we have part of the development team in Florida, part in South America, part in Pittsburgh, and a product owner in New York. The team discovers that the story they are working on has a disconnect between what is being done and what they think should be done. The team lead in Florida sends an email to the BA in Pittsburgh. She schedules an urgent meeting for an hour later with the whole team and sets up a conference bridge and a LiveMeeting. The PO is already on another call and can’t join. The South American team has some minor glitches trying to connect, but after about 10 minutes everyone has dialed in.
The BA starts with the issue – the very issue the lead in South America had been trying to bring up. He rolls his eyes to his team down there, who chuckles with the phone on mute. They finally discover that the way the Florida and South America teams have been coding this one feature are using different approaches after the Florida dev lead shares a Visio diagram he put together. It is decided that they will move forward with the South American way, and that the lead down there will work with on of the devs in Florida.
After the meeting, the dev lead in South America schedules a meeting with the dev in Florida. After some technical glitches, they finally share their screen. In describing the issue, they have to keep modifying and sharing back and forth a Visio document. Finally the Florida developer understands, and is able to share that with the team.
For some reason, we consider that a good way of working, and don’t realize how much waste is truly involved in that process. Let’s look at that same scenario with the team colocated.
No, connect this square to this circle
We find ourselves with the same team, with the same issue, except all members sit together in the same office. During their stand-up, they discover a disconnect in how one pair is completing the story from how a second pair is working on it. The BA rolls a whiteboard over, and they sketch out the disconnect. One of the team members rolls his eyes, and the BA catches it and asks him about it. The team member explains this has been a common issue, but ignored.
The team quickly discovers where the disconnect is, and the two pairs swap so they can show each other what they’ve been doing and get back to the common way. The BA and team lead bring the common issue up to the entire team during the Scrum of Scrums, and it’s quickly communicated and resolved.
But the rest of us live in the real world
Unfortunately, team colocation can sometimes be out of the control of the team members. Offshoring, outsourcing, remote employees and other aspects can lead to less-than-ideal situations. So when can a team be OK with not sitting together?
- Never – This might be a strong word, but the team should never be content that they aren’t able to colocate. With that out of the way…
- Open Communication – We need to be past many of the 5 Dysfunctions to know that when we have an issue, we can bring it up
- Excellent Tool Support – Conference Bridges, webcams, screen sharing, Skype, remote pairing tools and electronic whiteboards (or digital cameras for regular whiteboards) are all vital tools for trying to keep communication open.
- Team Agreements – Perhaps the best rule that I’ve seen in place on dislocated teams is to always use the webcam first, then phone, then email as a last resort. I’ve also seen teams keep open webcam links between two sites, with voice going to help increase the incidental communication factor
- One Team / Team Identity – Perhaps the worst situation is when you have two teams acting as a “team” but who have different values, different metrics, and different goals. Offshore / Outsourced personnel should have all of the logins, access and notification that someone working right in the office does. In other words – you should act as much as possible as one team
So while colocation may not be a stated principle of Scrum, it is vital for hyper-productive teams. While there are strategies you can take to be highly productive even with a dislocated team (see Jeff’s paper for ideals of how) in general, you have to have a mature, functional, high-communication team – and you may as well just colocate them.
Posted on September 7th, 2009
Perhaps the very first and most widely “adapted” practice in the Scrum world is that of the timeboxed iteration. Henrik’s Scrum Checklist identifies four subareas of concern:
- Iteration Length 4 weeks or less
- Always end on time
- Team not disrupted or controlled by outsiders
- Team usually delivers what they committed to
The original guidance in Scrum was 30 day sprints, but current versions of the Scrum Guide now recommend teams start out at two week sprints. However, even this isn’t enough for some teams – while some struggle to achieve working software in 6 or 8 weeks, others release working software every day. So how does a team know when to modify timeboxed iterations?
Here lie dragons
It is perhaps easier to start with the antipattern of modifying timeboxes. Unfortunately, these are pretty easy to spot – the team fails to meet their commitment during the scheduled timebox. This causes spillover into the planning game and to the next iteration with the team signing up for even more than they did the first iteration.
This usually continues for several iterations until either the iterations are “extended” (“This iteration is now 6 weeks long”), made longer (“We can’t do 4 week iterations, so let’s make them 8 weeks long”), or dropped all together. At this point the team is now without any guidance at all as to when things are going to be done. Long term release planning now becomes a complete guess as the team’s velocity is wholly unknown, and typically the entire premise on which agile was introduced becomes unravelled.
Perhaps surprisingly, timeboxed iterations are not to blame here. Indeed, it is the lack of self-reflection from the team – often based on immaturity as a working unit – which led them to spiral into a pit of disrepair. Let’s look at the team making two different decisions to alter timeboxed iterations which result in a much happier outcome.
If it doesn’t fit, it’s too big
Let’s say the team encounters the end of their first four-week sprint and finds that they did not make their commitment. And they over commit the second sprint signing up for more than they had in their first sprint plus the additional overwork to be done. By the third sprint, they seem hopelessly destine to be another agile failure. However, the team members, recognizing a bad thing happening, quickly gather the team. They decided on the tactic that if you can’t finish stories during a sprint – your sprint is too long. They decide to see what happens when they drop to 2-week sprints.
They discover that they need to break their stories down more, become more targeted in how they test, how they develop, how they release. Suddenly, what they couldn’t do in 6 weeks, they are regularly making happen in 2 weeks.
Or perhaps it doesn’t belong at all
Let’s look back at our team again. They are hopelessly stuck on their third sprint. However, instead of shortening the iterations, they decide to find out what is causing them not to meet their commitments. They discover that while the work flows through development just fine, it gets hung up during testing.
To solve this, the team decides to establish a Kanban board to visualize the workflow state of the work in progress. Additionally, because of the amount of items caught in testing, they decide to put a Work-in-Progress limit of 4 on the test column. That means that if there are 4 items in testing, no others can be moved to testing until the items are cleared. So the developers can’t move things along, encouraging them to jump in and help clear the backlog.
After several iterations of this, with the team applying the theory of constraints to find impediments, they discover that the “timebox” concept for flowing work doesn’t fit with their model. They have become so adept at it that each story is now approximately the same size, so estimation becomes a simple act of card counting.
Which team are you?
You’ll notice that the key outcome here is dependent on two factors. First – the maturity of the team and their ability to self-reflect to look for solutions (and try new ones). Second – the context of the work coming in. For our last team, if the business couldn’t feed stories into the pipeline that were about the same size, then other tactics might have to be put into place to allow for estimation and sizing.
So when you are considering dropping timeboxed iterations, ask yourself – are we dropping them because they aren’t of value? Or because we are afraid to face the real issues causing us from delivering value to our customers?
Posted on September 7th, 2009
Last week, Jurgen Appelo wrote an article called Scrumbuts are the best part of Scrum. I followed up with my Scrumbuts are the downfall of Agile post. Ultimately Jurgen and I are in agreement – it is important to be able to have the maturity to modify a process and not be holden to it’s ways when they aren’t working. However, it is vital not to just change a process because you lack the context to see when something isn’t working because of your team’s failings.
To help address, this, I’d like to take the high-level areas from Henrik Kniberg’s Scrum Checklist and discuss when it is and is not appropriate to modify them. They are:
- Timeboxed Iterations
- Team members sit together
- Daily Scrum
- Sprint Planning Meetings / Sprint Backlog
- Retrospective after every sprint
- Demo happens after every sprint
- Clearly defined Product Owner / PO has a product backlog
- Have Definition of Done
It is my hope that this series will help show the differences about when ScrumButs are a great thing – and when they most certainly are not.
Posted on September 3rd, 2009
I normally am in good agreement with Jurgen, but not in with his new article. The ScrumBut Ken argues against aren’t targeted towards mature agile teams.
The fundamental problem we have – in Scrum, in XP, in Crystal – is that teams don’t want to even *try* the practices.
- “There’s no way I can sit next to someone all day”
- “Our code is too complex to write tests first”
- “We don’t need stand-ups because we’re already communicating well enough”
It’s about context. If you’ve tried the practices, and have valid reasons why it doesn’t work for your team, and how you overcome that, then you are likely at an organizational maturity level past that which is the target of ScrumBut.
Further, there is nothing wrong with dogmatism when it is for the sake of learning and gaining context. Saying to a team, “I realize that we do X, but why don’t we go all out and try Y, since the XP book says that it is a good practice” – is that really a problem? It is being dogmatic, and then you use inspect and adapt against it.
My recent post about the CSM being the VB of Agile applies here. What gives the software development industry a bad name? It’s not the time to solve a problem. It’s that we don’t pick the right problems to solve, and when we do solve them, we can’t maintain or tweak them. That comes solely out of people not taking the time to actually adopt clean code practices.
Such is the case with the agile software world. What gives the CSM a bad name? The people who take a two day course, go back and cargo cult adopt Scrum in their organizations, don’t follow the practices (especially the one that says “Inspect and Adapt”) and then – and here’s the kicker – go to their conferences and say, “We do Agile!”
This is utter crap. When you are experienced, you know where to take shortcuts, where things won’t bite you. But when you don’t – and I’d venture to say that’s where a majority of Scrum people are – taking shortcuts isn’t just detrimental to your whole team, it’s detrimental to our industry and the goals to improve software development.
So yes, the “But” is a vital part of maturing as an organization. But (pun fully intended) saying, “If you aren’t tweaking Scrum then you aren’t doing it right” is, in my opinion, actually a harmful statement without the context of “once you’ve tried the practices for several iterations, and reflected as a team about what is working and what isn’t”
Now, does that mean a team shouldn’t start with a Kanban board? No. Not at all. If your team can level stories properly, can discuss flow states and is willing to give it a try, you are already past the maturity levels of a large majority of teams. I still think you should try both to be able to compare and contrast, but hey, if you don’t, I’m not going to fault you.
I’ll close this out with this. As a former Firefighter/EMT, there were plenty of times when we or our Paramedics had to stray from the norm to solve out-of-the ordinary solutions. But you only strayed once you had the experience and ability to understand the consequences of your decision. And until you had that, you trained and experimented and trained and reflected and discussed and trained until you did.
So I find nothing wrong with the default and general advice to be not to tweak until you have the context necessary to be able to tweak. And for mature teams, that may be early in. But you don’t know until you try, and saying you should tweak without trying I think has led us to the exact situation we’re in – an industry of unmaintainable, untestable, low quality, low value crap.