In this webinar, Jon Terry, COO of LeanKit, provides an overview of recently released product features and insight into what’s coming soon. During this discussion, you’ll learn: About our plans to help improve your overall LeanKit user experience. How parent-child board connections help you visualize work, track progress, and identify risk. Details about our upcoming Reporting and Analytics overhaul and how it opens […]
When I am speaking with executives, ScrumMasters and other leaders of change in organizations, I often present a simple 3-layer model to understand the relationship between the various moving parts in the Agile Framework:
- The Agile Values and Principles – These describe the culture and, in the Agile Manifesto, are the definition of the word “Agile” as applied to software development. I didn’t write the Agile Manifesto so I don’t get to re-define the word Agile. To give an example: in the manifesto it says “The best architectures, requirements and designs emerge out of self-organizing teams.” As a former enterprise architect at Charles Schwab, I struggled with what I saw as incredibly wasteful up-front architectural activities when I knew that developers would (sometimes) ignore my glorious ivory-tower plans! Therefore, if you are still doing up-front architecture and forcing your teams to comply to that architecture, you aren’t Agile. Therefore, as an individual, a team or an organization, you need to make a conscious decision to “BE” Agile or not… and if you decide not, then please don’t call yourselves Agile.
- The Agile Toolkit – There are many hundreds of distinct tools in the Agile toolkit including Scrum, OpenAgile and other “large” Agile methods, as well as the Planning Game, Product Box, Test-Driven Development and other “small” Agile techniques. Any group of people trying to BE Agile, will need to use dozens or even hundreds of different Agile tools. I call them tools because the analogy with construction tools is a very good one. Scrum is like a hammer. But you can’t do much with just a hammer. Scrum is a great, simple tool. But you always need other tools as well to actually get stuff done. All the tools in the Agile Toolkit are compatible with the Agile Values and Principles. Even so, it is possible to use the Agile Tools without being Agile. A Scrum team that never gets together face-to-face is not an Agile team: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” (Video conferencing doesn’t count.)
- The Agile Organization – When you start using a tool, there is a learning period. We start by being conscious of our incompetence and as we persist, we become competent… but it isn’t natural or habitual yet. Eventually, with continued use, we become unconscious of the tool. IDE’s and version control are like this in most organizations: we don’t even think about them! But getting through that initial stage requires us to change; to develop new skills. This process usually requires discomfort or pain (including psychological pain). An organization attempting to BE Agile and to use many of the tools in the Agile Toolkit will need to make many changes and often these will be difficult. For example, incorporating the Product Owner role from Scrum into your organization requires new role definitions, new performance evaluation practices and criteria, new compensation systems, new communication and reporting mechanisms, new authority and accountability processes, etc. etc. All of the changes required are about creating Enterprise Agility throughout the whole organization, beyond just software or IT. These extensive changes are often started in a very ad hoc manner, but at some point they need to become systematic. This is an important decision point for executive management: are we going to be Pragmatic about our Enterprise Agile adoption, or are we going to be Transformative about our Enterprise Agile adoption.
All of this is summarized in this graphic:
The Agile Framework [PDF]Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Steve Martin talks us through his session at Agile 2014 where he shares the challenges and outcomes from two separate transformation initiatives.
While both organizations are in rather risk-adverse industries (one financial and the other insurance), they invested heavily to introduce and scale Agile across an enterprise. Both wanted to transform their companies so that they could prevent severely dissatisfied customers from walking out the door, improve quality, and have better throughput, enabling them to respond to marketplace demands quicker.
One organization excelled – the other did not.
The post Steve Martin Rocks at Agile 2014 with an Experience Report appeared first on BigVisible Solutions.
Create your initial backlog, then stay on top of it. Here’s the how and why of Continuous Backlog Refinement.
In my previous article, I talked about compressed backlog refinement in which a backlog is taken from crude to well-groomed in a matter of days through a series of intensive refinement meetings with the whole team. The drawback, besides being several days of intensive meetings, is that we sometimes rush through some of the stories. We don’t have enough lead-time for other parties to do the work we depend on, and we don’t take a step back and look at the big picture. The pressure to get going causes us to not think clearly when looking for the minimum viable product of minimally marketable features.
In spite of its downsides, that approach may be necessary when you need to quickly refine an initial 1 to 3 month backlog and get a team sprinting. However, it’s not the best approach for refining and estimating additional user stories or subsequent backlogs. For that, we should employ continuous backlog refinement.Predictability
Most of my clients care about predictability:
For most companies we work with, the sweet spot is 3 to 6 months. If the product development organization can reasonably hit a 3 month commitment and have at least a high level idea of what things will look like 6 months out… that is something we can work with. — Mike Cottmeyer
It’s incredibly difficult to get a well refined backlog more than 3 months out using a compressed refinement approach. What I’m recommending, then, is planning ahead and staying ahead. Sure, if you need the compressed approach to get started, go ahead and refine that first 3 months of backlog. Then, immediately begin continuously refining the backlog for the 4-6 month time-frame.Continuous Backlog Refinement
Here’s what this looks like: As stories are written, have someone else on the Product Owner Team such as a QA lead, tech lead, or analyst review and improve them. Bring those stories to the next backlog refinement meeting, which you’ll have each sprint. Call it backlog refinement, call it backlog grooming, call it story preview, call it story walk-through, call it what you will, but have it as a regular standing meeting on the calendar and invite the whole team.
Come into this meeting assuming you will need to update and split stories. However, don’t update them in the meeting. Team members can take to-dos to split and update stories after the meeting. Stories that undergo significant changes will go through the next backlog refinement meeting. Let’s keep this meeting short and do offline whatever we can.
Resist the urge to go into detail on any story. Just a few minutes or less is enough. Remember, we’re grooming stories that are 3 months out. We don’t need to spend much time on them now.
Assume the stories are not ready to be estimated. Assume development and QA might want to go do some research on the stories before they are estimated. Encourage them to do so. Give the team time to do so. Estimate these stories in a separate meeting. Refining stories and estimating them are different kinds of thinking. Estimate with some skill and care.
This approach keeps both refining and estimating meetings short, but means you may need a more detailed story walk-through at the start of sprint planning (the “what” part of sprint planning). Those who did the intensive compressed refinement meetings might be able to get by with a more abbreviated sprint planning meeting.Conclusion
To get started with agile, when we have no backlog yet, we create and groom an initial backlog in a short period of time. We’ll call that compressed backlog refinement, and although it’s not the favored approach, sometimes you’ll just have to use that approach anyway.
Once the team is sprinting on your backlog, don’t let it dwindle down. You should have at least 2 or 3 sprints worth of well groomed stories, with acceptance criteria, ready for the team to implement. Most of the clients I work with need an additional 3 sprints worth of stories refined, but perhaps without the acceptance criteria. Stay on top of writing more stories and continuously refine your backlog.
Ken Rubin talks through Agile transformation beyond the teams, and how to effect true, lasting change in an organization.
The post Ken Rubin Talks Executive Level Agile with Dave Prior at Agile 2014 appeared first on BigVisible Solutions.
I don’t remember who suggested I read it or how it ended up on my kindle, but somehow I stumbled into reading “Unblock! A guide to continuous agile” by Andy Singleton. I was initially skeptical, do we really need a new way to do agile?
I started reading, and pretty soon I was hooked! I described the book to someone recently as a must read for coaches and Scrum Masters (and teams) who don’t understand version control with agile. I found the chapters on different version control systems and branching approaches vs feature switches excellent. The pros and cons of each were well explained, and I think even someone who isn’t a developer would be able to understand the different options. I’ve personally known for a while that feature branches whilst very popular can become a headache, but I’ve been out of development too long to understand what’s taken it’s place. I am now convinced feature switches are the way to go, thanks to this book.
The book doesn’t stop there, it takes a pretty radical approach to distribution, one that is not usually embraced in the agile community. In fact it’s pro globally distributed teams because of the benefits you get being able to hire the best people for your team regardless of where they are located. I don’t have a lot of experience with distributed teams working well, but the techniques mentioned in this book sound like they could work really well. If you are doing distributed agile, check out the suggestions here.
One of my favourite ideas is to stop interviewing people. Rather give them a job to do for a few weeks, even if it’s only a few hours a week because they have another job. At the end of the few weeks, discuss the work they contributed. Look at their code, and how they worked with the team. Then either offer them a permanent job or don’t. The reality is that no matter how good your interviewing technique is, it’s still hit and miss. But most of the people I know (myself included) can spot a bad hire in the first 3 weeks of them starting.
I must admit to being one of those touchy feeling hugging agile coaches that Andy mentions in the book, but I am glad to be able to say that I see a place for a different style. Andy’s book explains an approach that is pragmatic, based on technical excellence, and massively scalable. I highly recommend taking a look at his ideas.
The original keynote speaker, Aneesh Chopra, apparently had to cancel. His replacement, Sam Guckenheimer, provided an overview of Microsoft's journey to agile. It was an ok case study with some interesting information, but it wasn't a motivational keynote to get us all charged up. Talking to some of the organizers later, I found out they made a conscious decision not to pay for a headliner keynote speaker.
One of the more interesting talks was with Ron Jeffries and Chet Hendrickson in which they took questions from the audience. Everything from is TDD dead? (it isn't) to budgeting around technical debt. Ron and Chet showed their extensive years of experience. One point they hit on is that agile is really about the team figuring it out. The team has to own the process and make it work for them. Using something like a formal Scrum approach should only be your starting point.
Mike Cottmeyer did a good presentation on why agile adoption fails. He has a nice write-up on his website here and posted the slides here.
The last presentation I attended was with Jesse Fewell and Dana Wright. They walked us through a more engaging way to prepare for meetings & events based on Dana's book.
On the exhibit floor was the usual group of vendors, mostly tool vendors. Automating testing and continuous integration were big...and DevOps was being thrown around alot. I was reminded that Agile is a software conference, not a project management conference like PMI's Global Congress so the focus was really on software development.
A while back, I wrote about Cynefin, a framework for making sense of the world, and for approaching different situations and problems depending on how much certainty or uncertainty they have.
As a quick summary, Cynefin has five domains:
Simple / Obvious: Problems are easy to solve and have one best solution. You can categorise and say, “Oh, it’s one of those problems.”
Complicated: Often made up of parts which add together predictably. Requires expertise to solve. You can analyse this problem if you have the expertise.
Complex: Properties emerge as a result of the interactions of the parts. Cause and effect are only correlated in retrospect. Problems must be approached by experiment, or probe. Both outcomes and practices emerge.
Chaos: Resolves itself quickly, and not always in your favour. Often disastrous and to be avoided, but can also be entered deliberately (a shallow dive into chaos) to help generate innovation. Problems need someone to act quickly. Throwing constraints around the problem can help move it into complexity. Practices which come from this space are novel.
Disorder: We don’t know which domain dominates, so we behave according to our preferred domain (think PMs demanding predictability even when we’re doing something very new that we’ve never done before, or devs reinventing the wheel rather than getting an off-the-shelf library). Often leads to chaos when the domain resolves (I know least about this domain, but it’s way more important than I originally thought it was!)
By looking to see what kind of problems we have, we can choose an appropriate approach and avoid disorder.
However, we can also use BDD in conversation as a sensemaking technique!
BDD uses examples in conversation to illustrate behaviour. We sometimes call those examples scenarios, but really they mean the same thing. My favourite technique for eliciting examples is just to ask for them: “Can you give me an example?”
If the scenarios are imminent and dangerous, and we want to avoid them, we’re probably in chaos – and honestly, you won’t be having a “huddle” or a “scenario-writing session”; you’ll be having a hands-on emergency meeting. You’ll know if you’re in chaos. Don’t worry about talking through the scenarios any more. Get people who know how to stem the blood-flow into the room and throw some constraints around the problem like a torniquet (shut down that problematic server, or put up a maintenance page, or send an apology to your customers).
If the scenarios are causing a lot of discussion, and people are looking worried or confused, it’s probably because you’re in complexity. BDD is essentially an analysis tool, and analysis doesn’t work in complexity. You’ll see analysis paralysis, in which people try to thrash out various outcomes, and every answer generates yet more unanswered questions. As a check to see if you’re really in this space, ask, “Are we having trouble analysing this because it’s so new?” If so, see if you can think of a way to spike or prototype the ideas you’re generating, as cheaply as possible, so you can start getting feedback on them rather than deciding everything up-front. These are the 4s and 5s on my complexity estimation scale. We want to do these as early as possible, because they carry the most risk and the most value, so it’s very important not to push back on the business for clear acceptance criteria here! That will just end up pushing the riskiest requirements towards the end of the project, when we have less time to react to discoveries.
If BDD is working well for understanding the problem and gaining expertise in the business domain, you’re probably in complicated territory. Fantastic! BDD will work well for you here. People will be interested, and asking questions about scenarios generates a few more scenarios and helps create a common understanding. This is a 3 on the complexity estimation scale. Don’t forget to get feedback quickly anyway, because we’re all human and we all make mistakes. I tend to get devs to write the scenarios down, either during or after the conversations, since they can then get feedback on their understanding (or lack of it) early, before they even write any code.
If people are getting bored with discussion around scenarios, look to see if the problem is well-understood, or very similar to something that the team is familiar with. This is either a 2, which means it’s on the border of complicated and simple, and well-understood by people who work in that business domain, or a 1, which means it’s simple and obvious and easy to solve. You can always use Dan North’s “Ginger Cake” pattern here. Find a chocolate cake recipe that’s similar (“log in like Twitter”) and replace the chocolate with ginger (“but make them upload a photo instead of creating a username”). I find it enough just to name the scenarios here, without going into the actual steps. As a check, you can ask, “Is there anything different about <scenario> compared to <the other time we did it>?” That will help flush out anything which isn’t obvious.
The most important part of using BDD this way is to pay attention to people’s spoken and body language – bored, interested, worried or panicked, depending on the domain you’re in. I find BDD particularly good for locating the borders of complex/complicated and complicated/simple, and isolating which bits of problems are the most complex. And that’s how I use BDD across all the Cynefin domains, including the ones in which it doesn’t work!
(I’ll be teaching this and other BDD / Cynefin techniques as part of the BDD Kickstart open course with Cucumber founder Aslak Hellesøy in Berlin, 22 to 24 October – tickets available here!)
Characteristics of a progress-focused approach:
- Focus on the desired situation
- Use what is already there
- Learn from previous successes
- Take small steps forward
- Recognise and utilise the perspectives and ideas of the people with whom you work
Carol McEwan – The Managing Director at Scrum Alliance, takes us through the growth strategy and evolution of Scrum Alliance over the past few years.
The post Carol McEwan – Managing Director of Scrum Alliance – at Agile 2014 appeared first on BigVisible Solutions.
Alex Brown is the Chief Operating Officer of Scrum Inc. He has deep experience in Agile/Lean management techniques and business strategy. He is actively involved in adapting the Scrum methodology beyond its traditional home in software development into other creative team environments, and has a particular interest in pushing the envelope in financial and progress reporting in a Scrum context. His current research focusses on modular approaches to scaling Scrum in order to knit the entire enterprise together and achieve superior business outcomes.
Prior to joining Scrum Inc. Alex was a Principal at The Boston Consulting Group, where he led more than twenty projects to improve competitive positioning and transform fortune 100 companies to leaner and more agile operations. His project experience includes cases in the retail/consumer, IT manufacturing, healthcare, finance, and government sectors.
"To accomplish great things we must dream as well as act." -- Anatole France
Innovation is the way to leap frog and create new ways to do things better, faster, and cheaper.
But it takes slack.
The problem is when you squeeze the goose, to get the golden egg, you lose the slack that creates the eggs in the first place.
In the book The Future of Management, Gary Hamel shares how when there is a lack of slack, there is no innovation.The Most Important Source of Productivity is Creativity
Creativity unleashes productivity. And it takes time to unleash creativity. But the big bold bet is that the time you give to creativity and innovation, pays you back with new opportunities and new ways to do things better, faster, or cheaper.
“In the pursuit of efficiency, companies have wrung a lot of slack out of their operations. That's a good thing. No one can argue with the goal of cutting inventory levels, reducing working capital, and slashing over-head. The problem, though, is that if you wring all the slack out of a company, you'll wring out all of the innovation as well. Innovation takes time -- time to dream, time to reflect, time to learn, time to invent, and time to experiment. And it takes uninterrupted time -- time when you can put your feet up and stare off into space. As Pekka Himanen put it in his affectionate tribute to hackers, '... the information economy's most important source of productivity is creativity, and it is not possible to create interesting things in a constant hurry or in a regulated way from nine to five.'”There is No “Thinking Time”
Without think time, creativity lives in a cave.
“While the folks in R&D and new product development are given time to innovate, most employees don't enjoy this luxury. Every day brings a barrage of e-mails, voice mails, and back-to-back meetings. In this world, where the need to be 'responsive' fragments human attention into a thousand tiny shards, there is no 'thinking time.' And therein lies the problem. However creative your colleagues may be, if they don't have the right to occasionally abandon their posts and work on something that's not mission critical, most of their creativity will remain dormant.”Are People Encouraged to Quietly Dream Up the Future?
If you want more innovation, make space for it.
“OK, you already know that -- but how is that knowledge reflected in your company's management processes? How hard is it for a frontline employee to get permission to spend 20 percent of her time working on a project that has nothing to do with her day job, nor your company's 'core businesses'? And how often does this happen? Does your company track the number of hours employees spend working on ideas that are incidental to their core responsibilities? Is 'slack' institutionalized in the same way that cost efficiency is? Probably not. There are plenty of incentives in your company for people to stay busy. ('Maybe if I look like I'm working flat out, they won't send my job offshore.') But where are the incentives that encourage people to spend time quietly dreaming up the future?”
Are you slacking your way to a better future?You Might Also Like
If you want to change your game, you need to know what the key challenges are.
Innovation is a game that you can play much better, if you know where and how to debottleneck it.
In the book The Future of Management, Gary Hamel shares 3 challenges that he believes can help you unleash your organization’s capacity for innovation.
- How can you enroll every individual within your company in the work of innovation, and equip each one with creativity-boosting tools?
- How can you ensure that top management's hallowed beliefs don't straightjacket innovation, and that heretical ideas are given the chance to prove their worth?
- How can you create the time and space for grassroots innovation in an organization that is running flat to deliver today's results?
According to Hamel, "Make progress on these challenges and your company will set new benchmarks in innovation."
If I think back through the various teams I’ve been on at Microsoft, one team that I was on was especially good at helping innovation flourish, and we were constantly pushing the envelope to “be what’s next.” Our innovation flourished the most when we directly addressed the challenges above. People were challenged to share and test their ideas more freely and innovation was baked into how we planned our portfolio, programs, and projects.
Innovation was a first-class citizen – by design.You Might Also Like
Here is the deck from my Agile2014 talk on why many folks are struggling to adopt agile in larger, more complex enterprises. The presentation explores many themes persistent on this blog. Why agile works, why agile fails, what gets in the way, and how to systematically and pragmatically begin to refactor your legacy organization into an effective agile enterprise? If you came to the talk, I appreciate it. If you have any questions, please let us know. Thanks!
The post Why Agile Is Failing in Large Enterprises, And What You Can Do About It appeared first on LeadingAgile.
Certified ScrumMaster for Video Game Development
Kanban for Video Game Development
Below are my slides for my Agile 2014 talk: Agile Performance Appraisals without a number. If you missed the session is was recorded, so the video should be available on the Agile Alliance site in a few weeks.
The 4-Step Action Plan for Agile Health: Step 2. Understand how to adopt healthy Agile Mindset Practices and Lean Practices
Agile development requires a cross-functional, self-organized team to deliver potentially shippable software at the end of each sprint, with analysis, design, code developing and testing activities going on concurrently (not sequentially) within each sprint. Combining Agile/Scrum development with some of the lean methods is also becoming popular (so-called “Scrumban” methods). These methods emphasize reducing Work In Process (WIP), reducing feature cycle time and increasing throughput (feature completion rate).
In my blog on From Agile Pathologies to Agile Health I explained that some “agile” teams suffer from the following common pathologies, i.e., major dysfunctions in practicing agile methods, while claiming that they are “doing agile”:
- Agile development “sprints” assigned to software development lifecycle phases
- Agile development “sprints” assigned to technology tiers
- Mini-Waterfall inside sprints
While an agile team may not be exhibiting gross dysfunctions (pathologies) listed above, it may still behave in harmful or unhealthy ways that would prevent it from realizing the benefits of agile development, such as higher productivity, throughput and quality. Absence of major pathologies or sickness doesn’t imply health; agile teams may still not be healthy due to one or more harmful behaviors.
In this 4-part blog series, I focus on 6 harmful behaviors exhibited by agile teams and how to move away from them, and transition to 6 healthy agile-lean practices in order to get more benefits (improved productivity, throughput and quality). I also present 4 specific steps to transition to healthy agile-lean practices. Table 1 summarizes these 4 steps, and labels 6 harmful behaviors (as 1B through 6B) and 6 healthy agile-lean practices (as 1P through 6P) for ease of cross-referencing. Table 1 also indicates what is covered in each of the 4 parts of the blog series: Part 1 (highlighted in light green color) was completed. In this Part 2 (highlighted in pink color in Table 1), Step 1 – understand healthy “Agile Mindset” practices (1P and 2P) and 2 lean practices (3P and 4P) – is described. Parts 3 and 4 will be presented in the future.
Table 1: The 4-Step Action Plan for Agile Health
“Agile Mindset” practices to improve agile health: I now explain and recommend 2 specific practices to embrace an “agile mindset.” I typify an agile team B that consists of a business analyst, 3 full-time developers, 2 full-time QA testers, a Product Owner and a ScrumMaster. All members of Team B are full-time, dedicated members unlike the Struggling Agile Team of Part 1 of this blog series which had part-time, multiplexed members. As Team B follows all 6 healthy agile-lean practices (1P to 6P) listed in Table 1, it is our prototypical “Healthy Agile Team”.
I use a similar example of a typical 4-week (20 workdays) sprint for the Healthy Agile Team. Figure 1 illustrates the Sprint History Map of this 4-week sprint after the sprint is over. It uses the same format and legend as used in in the Sprint History Map of the Struggling Agile Team (see Figure 1 of Part 1). Each feature was broken down into its implementation tasks either during sprint planning or actual sprint execution. These tasks are indicated in the legend at the bottom of Figure 1.
Figure 1: Sprint History Map of the Healthy Agile Team following the
Agile Mindset Practices
The 2 “Agile Mindset” practices (numbered 1P and 2P below) require replacing the legacy mindset with agile mindset, moving away from silo thinking, welcoming the change necessary for successful agile adoption and implementing the required change to get the benefits of higher productivity, throughput and quality.
1P. Full-time, dedicated agile team members without multiplexing and with minimal multitasking: Move away from the old mindset that treats people as resources whose utilization needs to be maximized via multiplexing and multitasking. It is much more important that you maximize agile team throughput than worry about utilization of each team member as a resource.
Assign agile team members to work full time (100%) on a single agile team through all sprints of at least one release cycle. You need at least a full release cycles (4 to 6 sprints) for team members to understand each other’s strengths and weaknesses, develop a (hopefully smooth) working relationship, and jell together as a team. These well-jelled team members show higher productivity as they learn how to capitalize on each member’s strengths and compensate for weaknesses. They learn to work with each other as human beings, and not replaceable resources. This often requires a significant buy-in from management, if it is steeply rooted in traditional project management practices.
Cultivate the habit of doing focused work – one task at a time – starting with 30 minutes of uninterrupted work on a single task, and gradually extending it up to two hours. Then you will need a well-deserved 5-minute break due to intellectual fatigue. See The Energy Project: http://theenergyproject.com/ to understand how to conserve your energy to work in a highly focused way on single task at a time. Each team member learns to focus on a single task at a time (up to 2 hours in a stretch) until the task is over, before switching to other tasks.
Avoid multiplexing and minimize multitasking. It increases productivity by avoiding wasteful context switching, and making each team member committed to and accountable for the success of a single team. There are no divided loyalties of a person among different teams and projects. That simply doesn’t work well.
2P. Cross-Functional Team Members: An agile team is composed of cross-functional team members: Train, cultivate and invest in each member to become a “Master of One and Jack of Two”. Each member has primary expertise or mastery in at least one area, and working level skills in two other areas. From time to time, each person is needed to work in areas outside his/her own mastery. For example, a developer tests features developed by other developers, or a tester develops scripts for automated tests, etc. See: http://bit.ly/1lkaXHc.
Investing in team members to become “Master of One and Jack of Two” may require a significant buy-in from functional or departmental managers. Team members don’t just do their own tasks that match with their primary expertise or interest. They swarm as a team to deliver working features within each sprint. Each feature is worked on by a logical feature team swarming to complete the feature in the shortest cycle time. See: http://bit.ly/1rhtV6g. Although the Sprint History Map for the Healthy Agile Team (Figure 1) shows swarming feature teams only for Feature 1 and 2 for brevity, they exist for all 8 features in the backlog. These feature teams are “logical” teams in the sense that they may share one or more individual team members.
How to adopt two lean practices: These 2 lean practices (labeled 3P and 4P in the list of 6 healthy agile-lean practices of Table 1) are described below.
3P. Stop-Starting-Start-Finishing and work under WIP limit: Form swarming features teams within an agile team to focus attention on getting each feature accepted by the Product Owner as soon as possible. Without completing a feature or a task already in progress, resist the temptation to start working on a new feature or a new task. Stop starting new things (features or tasks) before completing the things you have already started. This is a good mantra for life too. This practice will effectively allow a lower WIP limit in an informal way.
As explained by David Anderson in his book “Kanban: Successful Evolutionary Change to your Technology Business,” 2010, page 114, the WIP limit needs to be set up as 2 to 3 people per feature plus 2 to 3 to smoothen the impact of a blockage. For an Agile team of 7 full-time, dedicated team members, the WIP limit can be set up as 3 + 2 = 5. You will need to experiment with this number and adjust it empirically up or down based on the experimental results. Progressively lowering WIP limits will bring out bottlenecks that need to be resolved. Agile Lifecycle Management tools, such as VersionOne, help you visualize the Kanban workflow under WIP limits, and provide warnings if WIP limits are exceeded. Learn how to work with smaller WIP limits.
As shown in the Sprint History Map (Figure 1), the WIPs on Day 2 through 17 (total 16 days) for 7 completed features (Feature 1 through 7) in the sprint are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 2, 2, 1, 1, with the average WIP = (46/16) = 2.875. The WIPs on Day 2 through 17 (total 16 days) for all 8 features are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 3, 3, 2, 2, with the average WIP = (50/16) = 3.13, which is only slightly more than the WIP of 46/16 = 3.13 for 7 completed features. The Healthy Agile Team has its focus on completing the work in progress before starting the new work by following the Stop-Starting-Start-Finishing mantra which reduces WIP. The Healthy Agile Team has a smaller WIP compared to that of the Struggling Agile Team illustrated in its Sprint History Map (see Figure 1 in Part 1, and the WIP data for the harmful behavior 3B in Part 1).
4P. Focus on minimization of cycle time: Improve team’s throughput (features completion rate) with cross-functional team members, eliminate NT events by avoiding multiplexing and multitasking, and use of proper test automation tools (see Part 3 of this blog series).
Reducing WIP reduces the cycle time. As shown in the Sprint History Map (Figure 1), the cycle times for the 7 completed features (Features 1 through 7) are 6, 8, 5, 7, 7, 8, 5 days, with an average cycle time of (46/7) = 6.57 days. I will now use the well-known Little’s Law to calculate the average throughput (rate of feature completion and acceptance by product owner) of the Healthy Agile team.
Average Cycle Time = Average WIP / Average Throughput, or alternatively
Average Throughput = Average WIP / Average Cycle time
In the example of Healthy Agile Team, Average WIP = 46/16 (see Practice 4P above), and Average Cycle Time = 46/7 (as explained just above).
Therefore, Average Throughput = [(46/16) / (46/7)] = 7/16 features per day.
You may use the Sprint History Map (Figure 1) to visually verify that the Healthy Agile team has delivered 7 accepted features (Features 1 through 7) in 16 actual work days of the sprint, confirming the average throughput of 7/16 features per day. Sprint History Maps provide visual data for WIPs and Cycle Times, and visual verification of Little’s law.
The higher throughput of 7/16 features per day for the Healthy Agile Team (compared to the Struggling Agile Team’s throughput of 4/18 features per day) can be attributed to the facts that the team has moved away from harmful behaviors: it has no NT events and substantially reduced number of impediments (IMP events); it avoided multiplexing and minimized multitasking, gotten away from the silo mindset, is practicing Stop-Starting-Start-Finishing lean mantra, has reduced long cycle times (average cycle time of only 6.57 days in a 16-workday sprint), and is practicing automated testing (as explained in Part 3 of this blog series).
Little’s Law is a powerful and versatile tool. A change in any one of its parameters (WIP, Cycle Time and Throughput) is most likely to effect a change in one or both of the other two parameters. You can reduce cycle time by reducing WIP while holding throughput constant. Or you may increase throughput by decreasing cycle time as we have just seen. There is a third option: a team may increase the average WIP (more work in parallel) and thereby increase the throughput, provided that the team can hold the average cycle time by increasing its intrinsic productivity by upgrading its skills via training and apprenticeship, getting more experienced members on the team, using various automation tools, increasing its design and code reuse, etc. If any one of these 3 parameters needs to be corrected or improved, Little’s Law tells us exactly what to do to achieve the desired results. Most of the time the goal is to increase throughput (without sacrificing quality) by reducing cycle time or by increasing team’s intrinsic productivity or both. Bennet Vallet of Siemens Health Care presents a great case study of Kanban success providing the details of how to harness Little’s law to reduce the average cycle time, increase the average throughput and improve the release predictability.
Lean methods provide us additional options to reduce the cycle time, and thereby, increase the throughput. Splitting large features into smaller features (they still must deliver value to customers) reduces the average cycle time. How small should these features be? Larman and Vodde suggest that for an N-week long sprint, each feature should take no more than N/4 staff-week of total effort (Reference: “Scaling Lean and Agile Development” by Larman & Vodde, 2009, page 120). For the 4-week example sprint used in this blog series, it would be ideal if each feature takes no more than 4/4 = 1 staff-week or 40 staff-hours (or less) of total effort. For a 2-week sprint, each feature should take no more than ½ staff-week or 20 staff-hours of total effort.
Furthermore, leveling the workload, i.e., having all features of roughly the same size also reduces the average cycle time. Uneven sized sprint workload (small features intermixed with medium and large features in a sprint backlog) increases the average cycle time.
As shown in the Sprint History Map (Figure 1), the Healthy Agile Team has swarming feature teams; each feature team is working on multiple tasks of a feature concurrently. For example, in the Sprint History Map (Figure 1), Software Design task (D) and Acceptance Test Development task (TD) were going on concurrently on Day 2, Code development task (C) and Acceptance Test Case execution task (TE) were going on concurrently on Day 4. This swarming action also reduces the cycle time due to intense collaboration among the feature team members, their focus on completing the feature and getting it accepted as fast as possible.
Sprint pipeline: Learn and apply the Sprint pipeline practice where feature analysis and UI design work is done one timebox ahead of software design, coding, testing, defect fixing, acceptance testing. This effectively allows two successive timeboxes for each sprint, but without adversely impacting throughput (it still produces working software at the end of each sprint). With sprint pipeline, feature specification and UI design is in much better shape when a sprint starts, compared to trying to squeeze all work for a feature in a single time box where analysis or UI design may become bottlenecks. In the Sprint History Map (Figure 1), there are no “A: Analysis” tasks at all, because the Healthy Agile Team is following the sprint pipeline well.
Is your team facing the challenge of moving away from harmful “legacy mindset” and “non-lean” behaviors, and is interested in transitioning to the healthy “agile mindset” and lean practices? I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).
Part 1: Understand harmful legacy Mindset and Non-Lean behaviors to move away from
Part 3: Understand how to use additional enablers of Agile Health
Part 4: Develop and implement your customized plan for adopting healthy agile-lean practices