Despite over a decade of focus on agile practices for software development teams, the truth is that agile is not just for developers. If you’ve been hanging out in the agile world for a significant period of time, you probably already know this to be true. Agile is not just for developers and it never was. But the real question is, how far can agile really reach? Can management really be agile? Some might say agile management is an oxymoron. But we disagree. Agile is for everybody!

In a wide variety of industries outside of IT, agile practices are the norm. It is simply a way of doing things that has grown organically out of the need for feedback and communication. Take, for instance, the graphic design industry. A graphic designer would never dream of rolling out new branding for a client without meeting with them continuously to run over each minor change as it occurs, adjusting the course of the redesign accordingly.

Here at 3Back, we practice agile techniques throughout every portion of the company, including Finance, Sales, Logistics… you name it. And we’re not the only ones. Lots of companies use agile outside of software development. For many of them, the hard part is getting agile into management. Could agile management be a reality? Based on our experience (and our own agile management), we say, “Absolutely!”

Lucky for us, Steve Denning, always pioneering innovation in management, agrees. In his recent article on Forbes, The Best-Kept Management Secret on the Planet: Agile, Denning asks the resounding question, “How do you get disciplined execution along with continuous innovation?” And here, the answer does lie with developers. Through the use of agile practices, development teams across the world are doing exactly that – providing disciplined execution alongside continuous innovation.

If agile development teams work, why not agile management too?

Epic

Work in Progress (WIP)   In kanban, the Stories that the Team is currently working on. (see Front Burner)  Kanban, is simple work item flow for teams. The word kanban is a Japanese word that comes from Toyota and translates as card. Kanban was used by Toyota manufacturing to limit inventory in production. The word kanban was lifted by the English Speakers (mostly USA) software community to describe a set of practices around limiting software work in progress. The notion of limiting work in progress has been around since the early days of piece work (early 1900′s) and before.

There are some common questions around WIP, Scrum and Kanban (the main idea in kanban)

• When you use a WIP is the sprint still there?
• Why limiting WIP important in scrum?
• Are scrum and kanban significantly different?
• Can the elements of Scrum and WIP be blended?

Good questions, with good answers, as follows:

1. The Sprint still defines the major Review Cycle. The Team still reviews the results of the Sprint with the Stakeholders on a consistent cycle. As usual, there is no partial credit in Scrum, so only the Stories that were completed in the Sprint get reviewed. The Stories that are still in the WIP at the end of the Sprint are not reviewed. As usual, this consistent drumbeat of Sprint Reviews is comforting to our Stakeholders, and also allows the Team to produce the Sprint-based metrics (like Velocity) the Stakeholders are used to.
2. The Team still does Retrospectives at the end of every Sprint in order to improve its process.
3. The Release Strategy is still modified at the Sprint boundaries, based on the Sprint Review and Stakeholder needs.
4. Each Sprint still has a Planning session to choose a Sprint Goal, and it is used as guidance when the WIP is updated.

Basically, all that has changed by adding the WIP to Scrum is to change the ‘choosing Stories to work on’ portion of Sprint Planning from a batch process to a continuous one – thus becoming Leaner. The Team still does its self-organization to meet the Doneness Agreements they have agreed to – which is the crux of Scrum – and virtually everything else is the same as usual. For more read Exploring Scrum: The Fundamentals

Agile Heuristic: Disciplined scrum teams only start something new, when they finish things and have manpower available.

Stakeholders are the reason we develop Product in the first place. Stakeholders are those people that have needs, wants, and desires (desirements). As a Scrum Team we are trying to identify work that satisfies our stakeholders. Stakeholders often (maybe never) seem to really know what they want and even when they see something they want they often change their minds. Figuring out what will really satisfy a stakeholders desire(s) takes a persistent effort of trial and error.

Stakeholders are vital to the Team’s success, as they review the Team’s Product and provide ongoing feedback. There are many people that are interested in the Product, but not all of them are Stakeholders – some are merely interested bystanders. Clearly identifying the stakeholders who hold the desirements is equivalent to identifying the market segment you are targeting.

So, What makes good stakeholders in scrum? Those people who fit the above criteria and who can provide feedback that helps the product evolve. Our big challenge is dealing with all of the other stakeholders who don’t help or just become part of the noise. Good teams need strong leadership, that can facilitate discussion and have a nose for good feedback.

The classic definition of Stakeholders is that they are people with legitimate interests in the project. Stakeholders are people who should not be ignored; they are people who can have a negative impact on the Team if they are not attended to. Scrum Team members are also stakeholders by the definition above but, the ones that we really struggle with are external to the team.

Know your stakeholders, know their needs/wants/desires and victory will be yours… or at least a quick trip to the ground

Scrum Alliance CSM Examination is changing…

Order Scrum Exam Prep

At 3Back we think this is good news for our industry. It takes our integrity up a level. We can’t imagine all doctors passing their exams simply because they answered questions. That would be crazy. While we are not doctors, we should expect high performance standards from our peers and colleagues who regulate our trade.

All of you who have taken the CSM exam previously, I am sure you answered all the questions brilliantly and contribute highly to your Scrum teams. To all of you who will take the exam after September 1st 2012, you know you will have earned your certification. All of us need to continue to move Scrum to the forefront of great development teams and beyond.

Any questions related to these changes should be directed to the  exam@3back.com

For more help Scrum Exam Questions

Order the Scrum Exam Guide

Agility is all about keeping things in balance, and knowing what can be manipulated and what can’t. This seminar discusses the different levels of agility found in an organization: writing code, team management, project management, and portfolio management. In each of these layers there are different things to manage, different things to keep in balance, and different realities to accept. Keeping this layering explicit makes management decision-making easier and more rational. Get To Done® get to done is the product owners tool set that manages the sprint to sprint productions of value. How are the other layers managed?

Technical Debt is what makes code hard to work with. It is an invisible killer of software, and must be aggressively managed. In this post I define Technical Debt and describe some of the issues.  In the past, I have stated that the ScrumMaster’s #1 issue on a Team is likely to be getting the Team to write Quality Code, which is code that the Team can change easily.  I noted that we (as an industry) know how to write such code, by using XP-like practices. Unfortunately, we often fail to do so. Technical Debt is the stuff in and around the code that keeps it from being Quality Code – that makes it hard to change. In other words, the term ‘Technical Debt’ refers to the debt that is owed to the code before it can become Quality Code. Often, people use the term ‘legacy’ (or even ‘instant legacy’) to refer to code with large amounts of Technical Debt.

I think of Technical Debt as being the viscosity of the code; it is what makes the code hard to wade through. One of the best metaphors I have for Technical Debt is that of going for a run. Working with Quality Code is like running in the park, in good weather, with shoes that fit. It is comfortable, and the Team can move quickly and with confidence. I like to refer to this a ‘6-minute code’ since it takes about 6 minutes to run a mile when it’s nice out, the course if flat, and you’re a pretty decent runner… On the other hand, there is ‘4-hour code,’ which refers to how long it takes to trudge a mile in the swamps, with a pack on your back and water up to your belly-button. The ratio of 6 minutes to 4 hours is 40, which is a reasonable (if anything, too low) estimate of how much more difficult it is to work with terrible code than it is to work with quality code. If you’re a coder, you know what I mean…

Definition of Technical Debt So, let’s take a closer look at Technical Debt. The overall concept is pretty clear; it’s the stuff that makes code hard to change. As you can imagine, this is a tremendous drag on agility, and having high amounts of Technical Debt is probably the number one impediment to Teams being agile. To be specific, having code that the Team is afraid of is the number one killer of agility. Technical Debt is not just about the code, though; there are other factors that come into play. For example, the code can be hard to change because of the quality of the code itself, lack of technical documentation, the development environment, 3rd-party tools, procedural impediments, organizational issues, and even the skill-level of the Team itself. Since it is the ScrumMaster’s job to help the Team remove impediments, each of these issues is something the ScrumMaster should worry about.

So, my definition of Technical Debt is: Technical Debt consists of deficiencies in the code, technical documentation, development environments, 3rd-party tools, and development practices, which makes the code hard for the Team to change. Now that we have a definition, let’s get some more discussion going in the comments below.

Get the Scrum Study Guide for more questions 

So, let me talk about the easy stuff first. One of the best things that can happen to a Scrum Team is that it finishes its work early in a Sprint. It amazes me that Teams are confused about what to do, but they are. So here goes… If the Team finishes early, it seems to me there are two choices: take a holiday, or do something new.

I have seen Teams take a half-day off if that’s all the time they have left, and I applaud this. In most cases, however, the Team should just bring something new into the Sprint and do it. By definition, the Items near the top of the Back Burner are Stories that are no more than one short conversation away from being agreed to; that is, the Team needs a short conversation before it can start work on one of them. So, the Team should work with its Product Owner to figure out which Story on the Back Burner to do. Maybe it’s something the Product Owner wants, or maybe the Team gets to work on one of the Chores (like some refactoring or something) that has been put off until later. It should be one that the Team thinks might fit into the time remaining in the Sprint, so they finalize the Doneness Agreement, task it out, and just do it.

Yes, it is really just that simple… unless the Team can’t find one that will fit in the time remaining in the Sprint. Then the Team can do one of two things: take a holiday, or just start a new Story, knowing that it will spill over into the next Sprint. In this second case the Story is actually part of the next Sprint, not this one. Now, that really wasn’t so hard, was it?

Learn More in Dan and Doug’s Book: Exploring Scrum: the Fundamentals: People, Product, and Practices