What does it mean for an estimate to be right? Does that mean that later actuals had the same numerical value? That the project length, or cost, or end date was the same as the estimate? Is it an indication of the “correct length of the project,” whether or not the project is done in that time? Or is there some better definition of “correct estimate” that we can use?
If we choose conformance to actuals as the definition for the “rightness” or “goodness” of an estimate, we’re certainly encouraging overestimation. It’s easier to overestimate and then waste effort as needed to be “accurate” than to underestimate and try to hit a possibly impossible target. Those who ask for estimates using this definition know this, so they are likely to arbitrarily cut the estimate in order to put pressure on development and prevent padding. Of course, those creating the estimate notice this tactic right away, and have incentive to pad even more.
Once upon a time, I was working on a hardware development project. We were breadboarding a design for a custom Large Scale Integrated Circuit using off-the-shelf logic ICs. As we were preparing to prototype our second revision of the design, we calculated how many of what chips we would need. Then we added another ten percent for chip failures, and some more of certain chips we might need if we had to expand the design. Knowing that the boss had a tendency to cut parts orders in half, we then doubled the amount before taking it to him. Unbeknownst to us, he had just come from a meeting where our project was declared to be top priority. To better support us, instead of halving the order, he doubled it. That’s right, the order was placed for four times our best estimate plus padding for contingencies. We couldn’t, of course, admit that we had doubled our estimate. So, we said nothing. The crowning blow came when, a few weeks later, the project was cancelled before the parts were all received.
This story illustrates the sort of dysfunction we create when we play games with estimates rather than treating them as what they are. Estimates are not promises. Nor are they controls on what development teams can do. They are rough calculations that allow us to make decisions before we have all the facts. They may be gut-level seat-of-the-pants guesses based on past experiences, or they may be carefully calculated based on considerable knowledge. In either case, they are the best answer we can give based on the current knowledge and the amount of effort we wish to spend on them.
What, then, makes an estimate right?
1. It didn’t cost more than it’s worth. If we spend a lot of time and effort estimating something that won’t change any decisions, then the estimate is wrong because it’s all a waste. If we estimate an entire project by breaking it down into hundreds of small pieces and estimating all the pieces, it’s likely more work than the resulting estimate is worth. And if the result is close to the decision threshold, we’re probably working on something of too little value.
2. It errs on the appropriate side. The calculation of ICs needed for the breadboard was intended to err on the side of too many, so that we wouldn’t run short and risk delaying the project. If we’re estimating time so that we know when to start other activities that need to be delivered with our project, we might want the earliest time we have to reconsider when to start these activities. If we’re choosing how much work will fit in our next iteration, we might want to be wrong in both directions an equal amount over time so that our long-term projections are more accurate.
3. It has an appropriate level of precision. If we’re estimating what we can get done in the next year, we don’t want to be working at the level of minutes and hours. False precisions is just noise. When I was a poor college student doing my grocery shopping, I estimated to the nearest dime because I found it embarrassing to have to remove an item after it was rung up. That high level of precision was important to me. The shopping cart held only a dozen dollars or less, though, not a hundred.
4. It’s the right thing to estimate. If we estimate the amount of programming time for a project, but ignore significant interruptions for other work, we’re not going to have a good answer for the elapsed time of the project. My estimate of the cost of the grocery cart contents in my college days was the right thing to estimate, because when I reached my limit, I could make substitutions in my menu plans to fit.
These are some of the things that make an estimate right, as an estimate. You can probably think of more, and I’d love to hear your suggestions.
Getting out of the Tardis and back into “posting” here on a regular basis is going to be like getting back on a bike after a long hiatus. I may fall and skin a knee sometimes; heck, I may even break a limb… but I promise nobody is going to die on this trip.
Sit back and enjoy and engage here when possible.
In my last posting I received many many encouraging comments (thank you!) and some that caused me to pause in some of my thinking about this whole blogging thing. It seems so very 2012 and earlier (remember this blog has been around since 2006 and contains a TON of content — some crap and some jewels).
Zooming into 2014 and I am spending a lot of time out on Twitter and with my business out of Facebook because for me this is more engaging and real-time (well… face-to-face rocks but I am not able to be everywhere at once). Google+ also seems to be an interesting place.
Apparently people still read blogs (eh hem, YOU are and I sincerely want to thank you). So… I promise to answer each and every comment here (the valid non-spam ones!) and engage with you and others here. It’s another way. It seems sort of one-way to me so let’s see how it goes.
While I stated in my last post that I’ve been “dark” — it does not mean I have not been working (and enjoying it immensely). I’ll share some of the current stories and travel stories and, more importantly… I will ASK FOR YOU HELP.
Asking for help is something I TOTALLY SUCK AT DOING. I don’t think I am alone at that.
Scrum specifically helps individuals, teams, programs, portfolios and organizations show you where the dysfunctions ARE TODAY.
And. As humans, we learn to live with these dysfunctions and they become the normal noise in life.
This noise can be obvious to people looking from the outside. People like me. And. You.
Here is what I am becoming more and more aware of on a daily basis:
Instead of just treating it like noise… listen to it.
Do ONE thing to make a change.
Who needs to do this?
Ask for help to solve it.
Stop with the idea that, “I’ve got this Mike” — because I will call bullshit on you my friend (well — if we have not met yet we are still virtual friends).
In my travels lately I have been really focusing on two messages — #DELIVER and SLOW DOWN.
People. We still suck at Agile (and Scrum) at the individual and team levels.
Now the rage is scaling agile (and Scrum).
This is not a new thing kiddos (or old people here #getoffmydamnlawn).
My experience is something to learn from — scaling the RUP (Rational Unified Process) from the team level to the Enterprise with the EUP (Enterprise Unified Process) [circa 2005 and earlier].
Is that experience applicable for all situations? Of course not; however, perhaps the next post will focus on what all the new “Silver Bullet” scaling methods, frameworks, and processes look like in 2014 (and what’s coming — because there is always something coming!).
There are patterns that work well. This is “noise” we need to examine a bit more and we will do that here together.
Blogging — it’s a chance for me to share experiences.
And. I will (wahoo right?!!?).
Until the next posting, let me know how you are doing with exposing things using Scrum – and how that experience is like turning up the amplifier to eleven all the time.
Ask SOMEONE for help.
I am going to do that shortly too (because as it has been pointed out — I cannot be a “one man show” on this journey).
The early adopters of Scrum were seeking a method of controlling the chaos of emergent product development processes. They needed empirical methods to discern if the product was moving in a meaningful direction. They were willing to risk accepting technical debt to validate working solutions in the hands of real customers. They were focused on delivering value, they wanted a process that optimized on value delivery and embraced the learning process required to explore new product domains. They were organizations capable of thriving on the edge of chaos. Organizations in the early adopters phase seek to keep options open (decide at the last responsible moment), to pivot upon learning about the opening market space, to fulfill an undefined emergent need.
"Intelligence should be viewed as a physical process that tries to maximize future freedom of action and avoid constraints in its own future." -- Alex Wissner-Gross
Tardigrade - an extremophileThese organizations are perhaps a small subset of all corporations - perhaps these are extreme examples - but they exist.
But extremophiles do not live in the calm waters of the Caribbean reef.
"Most executives I’m meeting with nowadays aren’t fundamentally trying to solve the adaptability problem." -- Mike Cottmeyer - Are we Solving the right problem?
The Agile movement has reached the late majority of the diffusion of innovation curve.
The Late Majority: "Individuals in this category will adopt an innovation after the average member of the society. These individuals approach an innovation with a high degree of skepticism and after the majority of society has adopted the innovation. Late Majority are typically skeptical about an innovation, have below average social status, very little financial liquidity, in contact with others in late majority and early majority, very little opinion leadership." -- Everett Rogers
My opinion is that this group is seeking a different answer than the early adopters or early majority. Studying Rogers' diffusion curve and synthesizing some other really observant human behavioral ideas; I think it's very obvious that the late majority have a very different answer to the fundamental questions around why they are adopting Scrum. I've asked this question for years in workshops. The answer's haven't changed. But the meaning behind the answers must be different than they were before.
Is it the value system of Agile that draws these companies into the Scrum trainers classroom? No. Is it the promise of the more collaborative and humane software development lifecycle for the employees? No, many of these companies have already shed their employees by adopting the staff augmentation model of the 20th C. consultant/contractor model.
The answer this group of late majority scrum adopters are seeking is: a lowering of the cost of development and maintenance of software systems that run and maintain the business. Very few projects that these organizations attempt are in the domain of seeking an innovative or emergent solution. Sure they speak the current lingo of innovations but few are seeking disruptive innovation (what must of us think when the "I" word is mentioned), most are seeking frugal innovation (15 Types of innovation).
"Frugal Innovation is about doing more with less. Entrepreneurs and innovators in emerging markets have to devise low cost strategies to either tap or circumvent institutional complexities and resource limitations to innovate, develop and deliver products and services to low income users with little purchasing power."
This group is not seeking to open up the future options that an emergent process may afford them.
See Mike Cottmeyer's blog series What Problems Are Executives Trying To Solve With Agile? It is a very good list - if you need an answer, pick one from his list - it's sure to impress.
Start with WHY - Simon SinekPerhaps we should start our agile transition with a serious question - Why?
I've asked this question, but just getting a few mid-level managers and the executive level sponsor answering this question may not be enough. Is there a method of hearing the organization - rather than the designated spokesperson for the organization? Enter Open Space Technology. Why yes, yes I believe this may provide a collaborative way to answer the question without the filter imposed by a leadership visor. Inside of the Agile movement it may best be expressed by Open Agile Adoption techniques.
Is Agile a solution for this cost reduction and predictable deliver of replacement solution domain of the late adoption mindset? I believe they can see benefits of adopting the basic foundations of Scrum. Of adapting the underlying Extreme Programming techniques that power the Scrum framework. Yet the agility of the processes might be antithetical to the organizations purpose of delivering software.
A case in point: a client in the data management of health care actually has the policy of allowing their clients to pick and choose (ala-carte) the software development process aspects that they are willing to pay for. For example - the client may not wish to pay for the QA on a project, so the development group conceives that it is their role to deliver a software product without doing the QA. Or perhaps the client doesn't want to pay for the project management aspect, or the architectural analysis of the solution. Now this is an extreme situation - true. One that none of us would like to be in - but can this organization adopt the Agile mind-set? When the various directors and VPs of this organization say they want to do the Scrum/Agile thing - do they mean what I think they mean - or are we talking about very different purposes?
Alex Wissner-Gross - A new equation of intelligence - TED Talk
Agile Scout's SAFe Review
In a recently published article, A Product Owner’s Syllabus, I shared how we educate product owners in our company. A product owner’s job requires competence in a number of domains, as it turned out. There’s one more consideration that I want to highlight. It’s rather related to the environment where this product owner works, not to personal skills or knowledge. Sometimes, though, it’s quite hard to draw the distinction between personal skills and how those skills are influenced by the environment.3 Levels of Product Ownership
Product owners can act on the following levels:
Mix of innovative and market-driven
Why is it important to single out these levels prior to doing drills in narrow disciplines included to the PO syllabus? This helps the trainees realize the high-octave “why” of this work. They say that philosophy is the mother of all sciences. In the same fashion, knowing the very reasons of why a product exists at all is the necessary first step. This knowledge and reasons are very product-specific. That’s why I’m skeptical about all kinds of “certified” courses, because attending a course and taking part in abstract drills (such as the ones brilliantly mocked at in here) will not turn anyone into a mature product owner overnight. To me, the best credentials for a product owner would be the history of the product that this person owned or managed, at least for some time, and the thinking that stood behind their decisions. There’s no better learning than by doing.
Just as in my recent post, where I anchored our evolving as a company with the way we do visual process management, I will look back at the history of our product yet again. We’re cool big guys, because we can look back as far as 10 (!) years ago. Targetprocess 1.0 was launched in 2004. Targetprocess 2.0 was released in 2006. Targetprocess 3 came on the scene around 2012-2013. The 1.0 version was the minimal viable and marketable software for agile project management. Targetprocess 1 had 7 releases, from 1.0 to 1.7. Targetprocess 2 had 24 sub-releases, from 2.0 to 2.24. With Targetprocess 3, we released the version 3.0.11 last week, and the next release will be 3.1.The Market-Driven Suite and Innovation
Looking at the releases from 1.0 — 1.7, and 2.0 — 2.24 (click the hyperlinked words above), one can draw some interesting conclusions. Targetprocess progressed with the agile movement and with what the market wanted( I wish we had a decision sequence timeline to track this better). The 1.0 version appeared as a result of market-based thinking, because agile was a rising new trend back then, and our product owner and founder (who has the project management background) wanted to do a decent software for agile project management. Then, with time, the 2.0 version was released. This was a re-written software with completely new UI. The product owner sensed that the product needs a robust core and an improved UI, before any new features could be added. That was a strategic market-based decision. Then after about 8 years of following the market, the product owner hits the level of innovation with Targetprocess3. It is indeed an innovative project management software as it brings along a new paradigm in visual project management. I do not intend to go too deep into praises, I just want to show with this story that it takes 8-10 years for a product owner to become mature and operate on the level of innovation. Some product owners never get to this level. They implement the features that make their product more appealing to users, to outperform the competitors, or both. There’s nothing good or bad about it, just the way it is. It’s quite rare nowadays that a completely new product comes as “innovative”. Start-ups are mostly busy discovering smaller niches in the established market and filling them in.A Basic Drill for Newbie Product Owners
Well, a product owner may or may not reach the innovation level. Let’s get down back to earth. I have this list of questions ready for trainee product owners to help them exercise their minds in product-based thinking as they consider implementing new features:
How often will people use this new feature?
How many people will use it?
Will this feature address any particular pain of users?
How it will help users save their time, if at all?
Will it make any difference, or will users be just as fine without this feature in the product?
Will this feature make the product easier-to-use or more complex?
Will it help bring new business, or is it meant for established users, mainly?
Formulating such questions can be a good exercise at an internal company training. The road to success starts with one first step, and this simple drill might be a nice first move in a career of a product owner, who might become an Innovator some day.
Rally believes that for-profit business can -- and should -- be a force for social good. That means we join companies like Ben & Jerry's, Patagonia, Method, and Seventh Generation in measuring business success by the triple bottom line: people, planet, and profit.
Rally is part of a growing community of nearly 1,000 Certified B Corporations from 32 countries and 60 industries, working together toward one unifying goal -- to redefine success in business as being not just the best in the world, but the best FOR the world.
Rally just completed its third, rigorous B Lab assessment, demonstrating our positive impact on community, employees, and the environment. The B Corp model helps us benchmark that we are living up to our own mission and that we push it even further.
What makes Rally a Certified B Corp? Here are a some highlights:
- Giving back to the community. In 2013, following our successful IPO, Rally donated $1.4M of founding equity to charitable causes and created the Rally For Impact Foundation, which enables engineers to apply their skills and expertise for positive social change.
- Providing free Agile education. Rally is working with innovative social impact organizations such as Rocky Mountain Microfinance Institute, where employee volunteers provide Agile coaching, training, business planning and team facilitation. In 2013, our employee experts also delivered “Act Like An Agilist” courses to social entrepreneurs at the Unreasonable Institute and Impact HUB Boulder.
- Treating employees well. We were honored in 2013 as "Best for Workers," scoring in the top 10% of all Certified B Corporations for our positive impact on the people of Rally.
- Paying People to Give Back. Our culture of giving encourages employees to spend 1% of their paid time volunteering, as well as giving back to their community on their personal time. As a result, in 2013 Rally employees contributed nearly 4,700 volunteer hours, or almost 600 worker days.
- Encouraging volunteerism from day one. Beginning this month, when new employees go through Rally’s onboarding “boot camp” they spend two hours volunteering.
- Shrinking our carbon footprint. Rally’s products are primarily deployed as Software as a Service (SaaS), which minimizes the creation or shipment of physical goods and optimizes the energy-efficiency of modern data centers.
- Recycling and composting at scale. At our office headquarters in Boulder, Colorado, where we employ about 60% of our staff, we’ve partnered with internationally-recognized nonprofit Eco-cycle to recycle and compost 74% of our waste.
- Getting to work with pedal power. Rally’s Boulder and Denver offices have a large bike-to-work population, and we offer all Colorado employees a company-paid EcoPass for public transportation.
As a Certified B Corp, Rally supports the movement for business to play a leading role in providing social and economic benefits to the world while delivering great products and services at a profit. Values-led businesses like Rally deliver shareholder value, while building trust among our customers and partners that we are in service to the global community.
We have a shared responsibility: we are collectively striving for shared and durable prosperity. Let’s B the Change.Geri Mitchell-Brown
This scaling problem has been studied.
"In 1957, British naval historian and management satirist Northcote Parkinson [known for Parkinson's law: “work expands to fill the time available for its completion”] painted a cynical picture of a typical committee: It starts with four or five members, quickly grows to nine or ten, and, once it balloons to 20 and beyond, meetings become an utter waste of time – and all the important work is done before and after meetings by four or five most influential members."
Scaling up Excellence
Why Big Teams Suck by Robert Sutton is a Stanford Professor and co-author (with Huggy Rao) of Scaling Up Excellence: Getting to More without Settling for Less.
Studied in Academia"After devoting nearly 50 years to studying team performance, the late Harvard researcher J. Richard Hackman concluded that four to six members is the team best size for most tasks, that no work team should have more than 10 members, and that performance problems and interpersonal friction increase 'exponentially as team size increases'.”
Studied in the Military"Some organizations learn about the drawbacks of oversized groups the hard way. Retired Marine Captain and former U.S. Senator James H. Webb explained why the “fire team” – the basic combat fighting unit – shrunk from 12 to 4 during War II. Webb wrote in the Marine Corp Gazette that this “12 man mob” was “immensely difficult” for Marine squad leaders to control under the stress and confusion of battle. Coordination problems were rampant and close relationships – where soldiers fight for their buddies – were tougher to maintain in 12-man teams."
Studied in Health Care"A Harvard Business School study by Melissa Valentine and Amy Edmondson of a large hospital’s emergency department [...] The crowd of 30 or so doctors and nurses who staffed the department at any given time were divided into multiple six person “pods,” each led by a senior doctor or “attending physician.” After the change, information about patients flowed more quickly and accurately and personal relationships improved markedly. Smaller teams reduced confusion and discomfort about who to ask for help and updates."
I think the general lesson learned is to not scale up, because the systems and structures that created and support the current organization will not bare the stress of scaling up.
Some alternatives to Scaling Agile:Scaling Agile – the Easy Way by Arlo Belshee
Try to re-structure the organization in a way that doesn't require efficiency of scale to achieve the goal. For example WL Gore's organizational pattern a team based flat lattice.
Or Semco, "a Brazilian conglomerate that specializes in complex technologies and services. Semco is a self-managed company. Workers at Semco choose what they do as well as where and when they do it. They even choose their own salaries. Subordinates review their supervisors and elect corporate leadership. They also initiate moves into new businesses and out of old ones. The company is run like a democracy." -- Podular organization: a business within the business written by Dave Gray.
Lessons from Semco on Structure, Growth and Change
Try a fundamentally radical idea like Holacracy. "Holacracy is a real-world-tested social technology for agile and purposeful organization. It radically changes how an organization is structured, how decisions are made, and how power is distributed."
Take a lesson from the US Government's FBI Case Management system.Case Study of a Difficult Federal Government Scrum Project: FBI Sentinel by Michael James.
Before you consider the leading market agile/scrum scaling tool-sets like SAFe, DAD etc. try this alternative approach: Open Agile Adoptions by Dan Mezick author of The Culture Game.
“Scaling is actually a problem of less,” says Sutton in The Do’s and Don’ts of Rapid Scaling for Startups. “There are lots of things that used to work that don’t work anymore, so you have to get rid of them. There are probably a bunch of things you’ve always done that slowed you down without you realizing it.”See Also:
The Agile Late Majority has different needs
The goal of software delivery teams is to deliver value, at least successful software development teams do this. Often, the term flow is used to illustrate the ability of a team to quickly deliver value. By way of an example, I want to provide a few patterns that interrupt flow – patterns that are common in most of the organizations we work with.
In many organizations achieving flow is much easier to interrupt than it is to establish. So what are the specific organizational challenges we face when we encounter impediments to flow and how can we create flow?Bernoulli’s principle
First an analogy. Bernoulli’s principle and equations in fluid dynamics are found in a variety of situations when liquid and gas are present. These principles are the reason why an aircraft is able to fly. Aircraft wings operate from air flowing over the top of the wing’s surface which is longer than the bottom surface of the wing. This faster air flowing on top of the wing generates a pressure differential that creates lift and propels airplanes into flight.
When impediments to flow are present we can reduce or even eliminate lift, leaving the wing unable to perform and obstructing flow through the system. Another interruption that can occur from the obstruction of flow is we begin operating too steeply. This leads to a situation called stall, which we can directly tie to what we see in many of today’s organizations. These interruptions to flow change the wing and contribute to it not performing well. In the case of a stall, recovery may be possible at great cost or not possible at all. Lets discuss some real challenges to flow in many organizations.Impediments to Flow: Team Structure
A common problem we see is around team structure. A fundamental principle of agile is to create stable cross-functional teams. This creates the correct shape for the wing that improves flow. The familiar forming / storming / norming / performing loop that all teams experience represent an improving wing design as they transition from forming to performing. Unfortunately, teams are often not formed to stay together. You know the pattern, form a project team and just at the moment in time that the team, or the wing, is performing well they are broken apart and new teams are formed for the next project. This creates churn, interrupts flow, and undermines the performance of the team. Once we have a wing that is performing well, leave well enough alone and bring the appropriate work to the team. This brings up a deeper topic around the importance of forming teams correctly which has been discussed by Mike, in Failure Modes of Team Based Scrum.Impediments to Flow: Lack of Co-Location
Challenges arise when organizations are unable or unwilling to increase co-location of team members. I’ve seen patterns where an organization will split teams up just to get some cross-architecture or cross product discussions started. In one situation, component or product area teams were split so each team had one person from each area and created a situation where there was very little co-location. Though there are certainly collaboration techniques that can help, I compare this to the challenges you have when frost or ice appears on a wing. It will work but at reduced efficiency and higher costs (why are we burning so much fuel?). This may be unavoidable but just as airlines must invest in de-icing capabilities a lack of co-location will require an investment in better collaboration tooling and more rigor in software development processes.Impediments to Flow: Non-Sustainable Operations
Wings are designed to function within a set of operational tolerances. If the aircraft operates outside of those tolerances then the integrity of the wing diminishes to the point of failure if the situation is not dealt with accordingly. Similarly, our teams have a natural cadence of delivery that is sustainable for the long haul. If they are required to operate outside of that cadence, they exceed the team’s tolerances for delivering quality work, then the integrity of what the team delivers diminishes. This may result in low quality, team member burn-out, and an inability to deliver.Impediments to Flow: Lack of Direction
Smooth air creates an opportunity for a wing to perform at its best. If the wing is asked to perform in great turbulence then it will operate with less efficiency and could stall. Similarly, teams need to have a clear understanding of the problems they are trying to solve which creates alignment across team members and across other teams. A lack of alignment is similar to operating with great turbulence, the teams churn, have a lot of rework, reduced quality, and unsatisfied customers.
I worked with an organization once that had been working on a project for two months. When the company brought stakeholders into the room to articulate what the problem is they’re trying to solve, it took over two hours to achieve a shared understanding on what they’re trying to accomplish. I expect the teams that had been working for the past two months had created value but I suspect it was a bumpy ride with some frightening moments. A clear direction would have created better alignment and allowed the team to operate more efficiently, better flow.Creating a Well Formed Wing
Improving flow will allow our teams to perform better, create more lift. Doing so is not something that happens by chance. Some things to think about to help your teams fly include:
1) Create the correct team structures, structures that allow the teams to stay together and operate well so that we can increase flow. And when we do increase flow it should be because the team understands the strengths and weaknesses of each other and they have a sense of performing together. Collectively they’re not the individual parts of the wing but instead they are actually performing together as wings in flight. Create smooth air and reduce churn so the teams can focus on delivering value.
2) Attempt to create co-located teams where possible. When unable to do so then make investments in de-icing such as better collaboration tools, increased use of video conferencing, and though more costly, increased rigor in your processes.
3) Don’t ask the team to operate outside of their tolerances for delivering well-working, high-quality code. Don’t break the wing. Understand what those operational tolerances are and respect them. Teams need to operate in a sustainable manner, at a pace they can continue to operate for the long haul. Don’t let them stall. Instead let’s have them perform well and deliver, as we need them to.
4) Let’s also create flow through alignment. We should be talking more about how we can create a solid vision and understanding of the problems we are trying to solve. We should be talking more about how we can frame the problem in order to obtain a clear understanding of what we are trying to accomplish. Let’s focus on providing the sufficient requirements and make sure the organization, in particular the product owner organization, is collaborating closely with the team, providing the team with the tools and the information they need to clearly solve the problems of their customers. Don’t push the team to work in turbulent air, which decreases their ability to perform and could cause them to stall.
I would love to get your thoughts on whether or not this analogy is useful. It made sense to me when it popped into my head but then again I have more things in my head that don’t make sense
Here’s to creating wings that have great lift and operate safely.
This incredible video of a Formula One pit crew in action has been making the rounds on the Internet lately. Have you seen it? The crew performs an entire pit stop in under three seconds, with no errors, working in perfect synchronicity -- like a “pit stop ballet.” Go ahead and watch, we’ll wait ... (it’s only 56 seconds, and safe for work.)
Watching this video got us thinking about the performance of Agile teams (hat tip to Agilista JessK.) Rally knows a little something about team performance thanks to the work of Larry Maccherone, Director of Analytics at Rally, and his Software Development Performance Index.
Using real, non-attributable data from the performance of nearly 10,000 teams, Larry’s analytics team looked at four dimensions of Agile team performance: productivity, predictability, quality, and responsiveness. What they found is pretty incredible evidence for how to optimize your Agile team performance.
To demonstrate, let’s use the F1 crew as an example. Each F1 pit crew mechanic has a distinct role, and performs only one job. In Agile terms, you might say that this crew has extremely low Work in Process (WiP.) And on an an Agile team, having fewer work items in process means that each item gets done faster. The amount of time that a work item spends in process is a measure of responsiveness. So lower WiP means faster time in process, faster time to market … and in the case of the pit crew above, highly responsive pit stops.
In Agile, teams with poor control over their WiP take nearly twice as long (see Time in Process on the Y-axis, above) to complete their user stories as teams with low WiP. This makes intuitive sense: as with the F1 mechanics, the more focused you are on just one thing, the faster you'll get each one done.
Lowering your WiP can have benefits besides responsiveness: teams with the lowest WiP have 4x better quality than teams with the highest WiP. When your job is to affix a tire to a car that’s going to drive more than 200 miles per hour, well … quality really matters.
But performance like that of the F1 crew comes with some costs. Though teams with low WiP may cut their time in process in half, and have one-quarter as many defects, they also have 34% lower productivity.
In Agile, productivity is measured by the number of user stories and defects completed in a given time period. Take a look at this NASCAR pit crew as an example.
NASCAR races allow a limited number of pit crew members "over the wall” during a pit stop, so each mechanic must be more productive. Changing a tire takes about 5 seconds, and each mechanic has to change 2 tires. While this crew may not seem as responsive as the F1 crew (its Time in Process is 13 seconds vs. under 3,) it’s much more productive.
Speaking of numbers: did you happen to count the number of mechanics on that F1 crew? There are a whopping 21 of them, standing around waiting for their car to pull in. By contrast, the NASCAR pit crew is limited to 7 mechanics. (The recommended size of an Agile team is 7 ±2.)
So what does this all mean?
- If your WiP is high and you’re at risk for missing a market window, then drive your WiP as low as possible by focusing on just a few things and getting them to market faster. In other words, make like an F1 pit crew.
- If your WiP is already well-controlled, however, consider your economic drivers. For example, if productivity drives your bottom line, don’t push your WiP too low. Instead, take more of a NASCAR pit crew approach. Balance is key.
Hungry for more?
- We’ve got our own videos of Larry Maccherone himself, explaining the team performance metrics.
- You can download the whitepaper if you prefer reading to watching; you can learn about the dimension of predictability in here, too.
- Lest you get carried away with the weight of performance metrics, make sure you check out the Seven Deadly Sins of Agile Measurement.
- Finally, stay tuned: if you're a Rally user, these metrics will soon be coming to a dashboard near you.
I’ve poked around the subject of visual process management in my previous articles, accentuating the complexity and non-linearity of software production process, and how a traditional Kanban board fails to visualize the diversity of organizational contexts and workflows. With that in mind, I’ve introduced a concept for a universal visual process management system that is capable to embrace this diversity and linearity on one screen, with flexible zoom-ins and switches, and called it Multiban.The Limitations of Kanban Board
Many software development teams suffer the limitations of Kanban board, at one point of their evolution or another. When a company grows, the scope of work grows as well, the structure of the company and of the teams, that it is comprised of, are changing, and what if one Kanban board is not capable to accommodate those changes? What if a large company is working on a suite of products, and a 1 team-only Kanban board cannot show the bottlenecks that are out-of-the scope for this team, but still influence its work? Or, what if the 1 team-only WIP’s are not relevant, because a suite of products is a sum of components, where each team’s work is a component of the whole product, and WIP’s and value streams have to be balanced on a wider scale, beyond the scope of one team-one project board?
We had to find answers to such questions. In 2012, Michael Dubakov published the Our Development Process: 50 Months of Evolution article. The changes that have occurred over 2012-14 are not covered there, but it still shows how our needs in visual process management were addressed in parallel with the changes in our company setup. Keep in mind that we are a very special company. We develop Targetprocess, agile project management software, since 2004, and we have an advantage because we are free to choose how to shape our product to make it respond to the changing needs and structure of our organization better. Over the last 5 years, we’ve been consistently working to make our tool more visual and more powerful. I will single out the major landmarks.2009: Switch from Scrum to Kanban
In 2009, we switched from Scrum to Kanban. By 2009, we’d been doing iterations for 3 years, and iteration development worked great when Targetprocess was a young product that needed to gain the critical mass and stay alive. Then, we realized — and that coincided in time with the uprise of Kanban — that we’d be better off reaching our goals as an organization if we practice development with Kanban. If you’re interested, here’s an in-depth story of the reasons and the production context that we had back in 2009. With our hands-on attitude, we didn’t linger with it, and implemented Kanban support in our project management tool. That’s how our Kanban board looked back in 2009 (one team-one project):
We implemented this Kanban board to cater both to our own needs, and to the needs of our customers.2010-11: Kanban is not enough. How about TeamsBoard?
While the major reason for our move to Kanban in 2009 was the change in the product development dynamics (the product matured, and we needed to switch to the “add features” mode), the major change in 2010-11 was the switch from one team to many teams, as we realized that this setup works better for the “add features” mode. The count of feature teams is not fixed, it changes depending on which features we’re doing at the moment. So, we felt the need to visualize the work of many teams on one board. Hmm. That’s not what a simple Kanban board was able to offer us. That’s why, as hands-on as we are, we poked around and came up with what we can now call the forefather of Targetprocess 3. Take a look at TeamsBoard, edition 2010:
This board doesn’t look too fancy now, in 2014, but back then it was surely a step ahead compared to a simple Kanban board. One can see backlog, and work in progress for many teams. If some states had their WIP limit exceeded, the TeamsBoard would show it. In the screen above one can see that WS team had the bottleneck with 3 bugs and 1 user story resting in the Coded state. Then this work of testing could be shared with the other two teams. The TeamsBoard also allowed zooming in on each team, and what they do, by person.2012-14: Targetprocess 3 and Fine-Tuning Process Visualization
Then, as we realized that sky is the limit, and visualization has enormous potential for project management, and for our own needs, we moved forward with the concept of the tool where anything can be visualized, depending on the changing dynamics and goals of a company. The fundamental idea is to offer a flexible tool that adapts to any process and follows any organizational changes. The other fundamental principle is the switchability of visualizations. We do not have stakeholders who tell us what to do and what to implement next. Our feature teams and our customers are the stakeholders. They tell us where else they need flexibility, and our backlog is formed based on those needs. We run recurring UX Process Visualization sessions, to see where else do we have yet to make room for more visual flexibility. We stepped aside from the traditional Kanban as the visual process management system long ago, and what we are now having is Multiban a visual process management system that supports any development process, for any number of teams and any number of projects, with cross-team and cross-project planning, using timelines for roadmapping, views as reports, etc. This screen from Targetprocess 3 is related to the good old Kanban of 2009 only by its board-ish looks, while in reality it is a switchable slate of views, zooms and perspectives.
It’s time to say a few words about Multiban now. Perhaps, the fastest way to explain how Multiban differs from Kanban is to use a metaphor. Multiban can be compared to the 17-inch interactive screen as in Tesla luxury electric cars. This awesome screen is a one-spot customizable dashboard for media, navigation, communications, cabin controls and vehicle data. Multiple Kanban boards for one suite of products (or a related suite of features, as in our case) can be compared to putting many touchscreens in the car, or even to using plastic controls for each of those functions. Would a driver feel more comfortable using one smart touchscreen? Or many simple screens? Or many knobs? It depends. For one thing, no doubt, the super-fancy touchscreen would require a learning curve. If a driver is OK with various controls, and if they do not depend on each other, then probably the car and the driving will be OK. Switching back to knowledge work: too many things are interrelated in software development, and losing track of those connections can have a bad impact on the way the work is done . It’s hard to keep everything in mind, and use visual board as a polished parade version of a development process. Multiban, as the visual process management system, is presented by a set of views, reports, controls and boards that comply with any diversity, and any complexity of workflow, or organizational structure. Targetprocess 3 is the only digital tool that supports Multiban at the moment. The concept of Multiban is the by-product of our organizational evolution, which dictated the need for evolutionary changes in our visual process management. Now we are ready to share what we’ve learned and implemented with other organizations that have been evolving, or will be evolving, in a similar fashion.
Immer wieder frage ich mich in meiner Rolle als ScrumMaster: „Was kann ich dafür tun, dass mein Team schneller wird? Wie kann ich es anspornen?“
Was sind Motive, um schneller zu liefern? Unterscheiden wir zunächst zwei Kategorien der Motivation. Die intrinsische, also die Motivation von innen heraus, und die extrinsische, also die Motivation von außen. Hier einige Beispiele:
- Die Arbeit und ihr Ergebnis begeistern mich.
- Das Ergebnis hat für mich persönlich einen greifbaren und spürbaren Nutzen.
- Angst um den Arbeitsplatz/vor den Konsequenzen bei Verzug, auch ohne spürbaren Druck von außen
- Ich weiß, welchen Anteil/Beitrag ich leiste.
- Ich weiß, wohin die Reise geht.
- Ich bin innerhalb eines für mich guten und nachvollziehbaren Rahmens selbstbestimmt in meinem Handeln
- Druck von außen (Chef, Projektleiter etc.)
- Prämienzahlung bei Termintreue und stimmiger Qualität
- Anerkennung vom Chef/Vorgesetzten.
- Konkurrenz anderer Teams/Projekte/Unternehmen
Idealerweise arbeitet jemand effizient und liefert entsprechend schnell und in guter Qualität, auch ohne dass wir etwas tun. Das Leben ist aber nicht immer ein „Ponyhof“ und so sind doch immer wieder einer „Beschleunigung“ von außen und Motivationsspritzen durch den Scrum Master nötig. Ich möchte also die Frage stellen: Wie motiviert ihr euer Team? Oder. Wie bringt ihr das Team dazu, vielleicht sogar für euch zu rennen? Hattet ihr schon einmal einen Team Lead/Chef/Vorgesetzten, den ihr so sehr geachtet habt, dass ihr schon aus diesem Grunde für ihn oder sie gerannt seid? Eine ideale Situation, oder?
Als Geschäftsführer habe ich die Erfahrung gemacht, dass genau hier ein wichtiger Hebel liegt. Es steht zwar in keinem Buch geschrieben, aber der ScrumMaster ist in meinen Augen auch für die Stimmung im Team zuständig. Wie heißt es doch so schön: Der Fisch beginnt beim Kopf zu stinken. Oder: „Zeig mir dein Geschäft und ich zeig Dir deinen Chef.“
Tun wir also etwas dafür, dass das Dev Team gerne liefert. Sorgen wir für Stimmung und dafür, dass die Mitglieder gerne zur Arbeit kommen und gerne in diesem Team arbeiten. Genau dafür braucht es ja die berühmten Soft Skills, wie die Fähigkeit, Konflikte zu lösen oder als Schlichter und Moderator zu agieren, um Frust zu vermeiden etc. Warum nicht also den Witz des Tages einführen oder ein regelmäßiges Teamfrühstück durchführen? Auch mehr oder weniger große gemeinsame Teamevents können helfen. Dies sollen keine pauschalen Allheilmittel sein. Jeder sollte herausfinden, was dazu führt, dass ein Teammitglied sich noch wohler fühlt. Wichtig ist jedoch, dass Konflikte gelöst und nicht unter den Teppich gehören. Machen wir uns bewusst, dass Stimmung immer herrscht, ob wir sie nun gerade sehen oder auch nicht. Aber sie ist vorhanden und sie bewegt und leitet unsere Teammitglieder. Machen wir sie also lieber sichtbar. Beispielsweise durch eine Frage danach in der Retrospektive. Eine Freude für alle, wenn sie ohnehin gut ist. Eine Chance jedoch, wenn sie gerade nicht gut ist, denn sie wirft die logische Frage nach dem “Warum” auf. In der Retrospektive des vergangenen Sprints fragte ich alle Mitglieder nach ihrer Stimmung auf einer Skala von 1-10, wobei 10 die Bestnote war. Im Durchschnitt lag unsere Stimmung bei wundervollen 8 Punkten. Ein tolles Ergebnis, aus dem ich ableitete, dass diesbezüglich keine dringenden Maßnahmen nötig waren. Und vielleicht könnt ihr euch vorstellen, was dieses nun transparente Ergebnis in den Gesichtern der Teammitglieder bewirkte.
Fragt euch am besten also selbst nach den Gründen dafür, warum ihr gerne in einem bestimmten Umfeld arbeitet und lasst euch davon leiten. Frei nach dem Motto: Ich behandle die anderen so, wie ich selbst gerne behandelt werden möchte.
- Scrum Essentials: Die sieben Fragen der User Story
- Der ScrumMaster als Dienstleister
- What´s S.C.R.U.M. ?
Natalie Warnert (@nataliewarnert) blogs at Confessions of a New ScrumMaster. Here she is, talking about dating Agile.
So I’m being an Agile player. I’m dating a few different versions of Agile to see which works best while trying to keep it from the other methods I’m test driving. Don’t tell Scrum that I was scoping out Kanban. Don’t let Kanban know I made a date to get to know TDD better. How can I help the team decide which is best when there are so many options to consider? A hybrid approach can sometimes work, but under some corporate guidelines the relationship needs to be with one or another exclusively, not multiple. It’s all about exclusivity in this corporate Agile dating world. (I plan on posting a subsequent post exploring the non-exclusive relationships and hybrid approaches to this in the future – check back).
Honestly I’ve only tried each for a short time, so it could be too soon to tell. How long do you date one until you decide to make your relationship and commitment public? There is the get-to-know you phase where you’re just trying to figure out what each methodology is about, what they stand for, and what they work best for. It has to be determined if they are compatible with the team and project and if the relationship will work in the future.
Once you have an idea of which you want to commit to, how can you be sure? Should you keep the others on the line in case it doesn’t work out? If there are a few things that don’t work in one, do you try to tweak those things at the risk of losing the integrity of the methodology itself? What are the long term consequences of not being able to make a commitment? Obviously methodologies don’t have feelings but teams do, and how do you help the team to determine what is best without causing them unnecessary pain and confusion?
Does the team settle for what works “well enough”? Where they and the stakeholders can be happy? But what is to say there is not more happiness out there to be found? That hopefully should be found as the team improves and continues to inspect and adapt for what works best for them. There are things in methodologies, like people, that won’t change in relationships, but there are other things that can and will change as the relationship grows and matures. Goals get more defined, it becomes more comfortable, but there will still be and should still be ups and downs. That is how the relationship continues to improve and get stronger. Maybe at some point if the team or project changes too much the relationship will need to be ended, but that shouldn’t be looming overhead. If it ends, it simply means the team and the methodology grew apart and will need to look to start dating again.
It’s okay to be an Agile player at the beginning but in some corporate PMO run environments, the non-exclusivity does not work for very long. It’s best to go in with your eyes open, learn as much as you can quickly, and help the team to make an informed decision for what methodology they should have a commitment with.
This post first appeared as I’m being an Agile player on Natalie’s blog in June 2013.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
It’s very common for organizations to track the velocity of the Agile teams over time. This is quite a reasonable datapoint to plot. Combined with other data, it might give you some insights when you look back, and insights based on data are typically more useful than insights based on opinion. Remember, though, to keep in mind what the data is, and what it is not.
In the case of velocity, it’s not an analog for productivity. It’s easy to fall into the trap of thinking so. “28 story points is the amount of work we can accomplish in a sprint.” Except 28 points is not an amount of work; it’s an estimate. Even if you count stories rather than estimating them—”17 stories is the amount of work we can accomplish in a sprint”—it’s still an estimate. We can easily manipulate either one by estimating with more story points or slicing the work into smaller stories. It’s so easy, we can do so without noticing or intention to do so.
Goodhart’s Law: Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
In other words, while velocity may roughly track productivity, it will cease to do so as soon as we use it for that while trying to increase productivity.
This misuse of velocity to represent productivity is well-known, but I frequently still hear or read statements that conflate the two. Pick something actually valuable to you if you want to measure productivity.
Many organizations have trouble communicating effectively between executives, product owners, and developers.
Because they are trying to decompose high-level epics into granular user stories.
Features are needed to scale, because it’s too difficult to manage large programs with just user stories.
What’s the best way to use Agile features to manage large enterprise programs?Agile Features
I recently worked with a large mobile telecom where the organization had been breaking epics directly into user stories. They were experiencing issues and didn’t find it effective to go from big, high-level epics to small detailed stories. This is a challenge I see at a lot of organizations and there is a simple solution, features.
Features are needed to scale, because it’s difficult to manage large programs with just user stories. Release planning becomes too detailed if you don’t have a middle tier of features representing what you’re trying to build. Without features you lose the ability to coordinate across teams effectively and are not able to provide enough context about the higher level value and goals. You need features to define the product, coordinate, and plan what you’re going to build at the delivery team level.
It is much more effective to discuss what the development teams will deliver in the future by describing it in high-level features, particularly for folks at the senior leadership level, senior product owners, and executives. User stories do not resonate with them, because they’re too granular. A senior executive doesn’t want a list of two-hundred user stories that you’re going to deliver in the next release. They don’t have time for all that detail. They want to talk higher level about what key capabilities are going to be delivered in this release, six months or a year down the road.
You apply a lot of the same rules for features that you do for user stories. You deliver features frequently, synchronize your work across teams, and limit your work in progress for features just like you would for user stories.Tips for Agile Features
There are a few rules that I try to impart when I’m dealing with features. I like to allow features to span iterations, but I generally don’t want features to span releases. By that I mean, if you have a product release six months down the road, you want to make sure that you’ve got all the features you’re going to build within that release and you don’t have a feature that’s partially in one release and partially in another release.
It’s important that your organization doesn’t feel like the product roadmap and features are etched in stone. The features may change based on new challenges that the team has discovered. You may discover that one particular feature is going to take longer than you expected, and so it’s important to review this feature set in a regular cadence with senior leadership, so they know what to expect in the future. Don’t set the false assumption with senior executives that the feature set is fixed and it’s not going to change. This is software, and things always change. Contrary to popular opinion I find executives are pretty amenable to change. They just don’t like surprises.
When you define features, they need to be associated with a particular goal of the system. If the feature does not align to a particular goal you may start having feature creep and orphan features. Your product owner team should be responsible for making sure each feature is aligned with a specific goal. The product owner team should take the big picture that’s being discussed at the portfolio level and decompose those long-term objectives into release-level features. It’s also their responsibility to take those features and help decompose those into user stories. I recommend you do that by defining the product roadmap and conducting roadmap workshops or release planning workshops.
Another important responsibility of your product owner team or core product team is to make sure that dependencies between features are managed. The best way to do that is to make sure there are as little dependencies as possible and to make sure that features are as self-contained as they can be. Ensure features are not dependent on aspects of other features.
Just like user stories, features can be described in what we call the traditional “Three C” format, card, confirmation and conversation. The three C’s help your team gain a shared understanding of the feature. You can confirm your shared understanding of features with acceptance criteria and visual specification. The visual specification can be a use case diagram, sequence diagram, wire-frame diagram or mock user interface. Just provide a visual representation to describe what product capability the feature provides.Summary
I hope I’ve inspired you to look into whether features would help your organization. If you are using features, I hope you’ve found some value in revisiting the best way to utilize them. If you are not using features, take some time to investigate if there are communication break downs when product owners are breaking their epics into user stories.
What are some tips you have for using user stories?
The post How to Manage Large Agile Enterprise Programs with Features appeared first on LeadingAgile.
Neulich kam ein etwas resigniertes Projektmitglied ins Büro uns sagte zu mir: „Wir haben alles noch schlimmer gemacht – wir haben es verscrumpelt!“
Er bezog sich dabei auf recht komplizierte IT-Controlling-Aufgaben und Prozesse zwischen drei Organisationen. Mich hat es aber insofern getroffen, als dass er die Wortschöpfung „verscrumpelt“ ja nicht ohne Grund aus dem Hut zauberte. Offensichtlich empfand er die Veränderungen, die durch die Einführung von Scrum ausgelöst wurden, als negativ. Und das erlebe ich nicht zum ersten Mal. Bei dem Versuch, so einfache Abläufe und Beziehungen wie Scrum sie vorsieht, einzuführen, werden die hoch regulierten Strukturen und lange gewachsenen und ausdetaillierten Prozesse grundsätzlich in Frage gestellt. Vor der Veränderung hat das System in Bezug auf Agilität nicht gut funktioniert, aber es war im Gleichgewicht und hatte einen Weg gefunden, mit den Aufgaben umzugehen.
Nun verändern wir ein kleines Teil im Getriebe oder Uhrwerk und die Auswirkungen sind enorm. Und dabei kann man nicht mal alle Auswirkungen vorhersehen und wird daher das eine oder andere Mal überrascht. Was wir für die Softwareentwicklung fordern, gilt in diesem Falle auch für die Organisationsveränderung. Neue Prozesse entstehen, indem man sie ausprobiert und lernt. Das kann in den ersten Anläufen frustrierend sein und so wirken, als wenn man alles noch schlimmer macht. Vor allem für Menschen, die klare Strukturen brauchen und alles vorab bis ins kleinste Detail durchdenken und planen wollen, stellt diese Vorgehensweise eine Herausforderung dar.
In solchen Fällen versuche ich, den Anspruch der Personen auf die Optimierung des Prozesses oder der Rahmenbedingungen zu lenken. Skizzen des „optimalen“ Prozesses und die Visualisierung der Stellen, wo es momentan noch „kracht“, können die Enttäuschung der Personen konstruktiv werden lassen.
Ich habe dann vorgeschlagen, dass wir gemeinsam versuchen, die neuen Prozesse so zu verbessern, dass wir sagen können, wir haben sie „verscrummed“ und nicht „verscrumpelt“. Seitdem biegt sich die die Frustrationskurve allmählich in eine Steigerung des Level of Done nach jeder Iteration. Vielleicht hilft uns ein Board, auf dem wir die Prozesse und Abläufe unter „verscrumpelt“ sammeln und nach und nach Richtung „verscrummed“ bewegen. Das würde die Impediments schön transparent und wahrscheinlich handhabbarer machen. Mal sehen, was der Kollege davon hält.
- Scrum Meetings – Spannungsfeld Routine versus Kreativität | Dieter Rösner
- Mit dem Computer Code bessere Teamarbeit erreichen
- Die Scrum Artefakte
I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.
Some signs you may have a problem introducing a change:
- Taking action requires getting permission (this is straight from Pawel)
- Action can’t be taken because projects are too important to risk
- Only certain people can take action
I have a great example of this happening recently: The group I was with raised an impediment. I had a nifty new impediment display that I wanted to try out (impediments displayed on a big monitor that everyone in the company could see). I sat down to add the impediment to the list, and then I had to pause…because the impediment called out something that might upset some folks. It might REALLY upset some people. I ended up not displaying that impediment. Why not? Was I just a chump? Was I too scared to make an impediment visible? Maybe…
Or perhaps I understood the culture well enough to know that certain things were acceptable to display as impediments, and others weren’t. That’s just the way it works at some places.
The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.
Filed under: Agile, Coaching, impediment Tagged: Agile, blog, Continuous Improvement, culture, Impediments