In Scrum and other Agile methods, a common way to manage feature requests is with User Stories. I’ve been teaching people about User Stories and doing workshops with teams for a long time. Out of that work, I’ve created a very simple PDF User Stories and Story Splitting reference sheet that might be handy. Please feel free to download it and share it. This document is something that I explain in-depth in my Certified Scrum Product Owner training seminars.
There are a number of sites out there that include some details that are left out of the reference. Please see, for example, “Patterns for Splitting User Stories” by Richard Lawrence. See also the great foundational article on “INVEST in Good Stories” by Bill Wake.
- Encourage multilateral communications and dialogue among peers and between employees and leaders. Offer workers a shared sense of ownership in company goals and mission—encouraging employees’ sense of voice, position, significance and purpose.
- Establish strong company values that employees can understand and know how to practice—increasing their sense of belonging, purpose and security.
- Set challenging but achievable goals—to increase employees’ sense of challenge, learning and autonomy.
- Shift the focus from hierarchy to community—connecting employees to one another in ways that empower them and increase their sense of belonging, connection and security.
- Ensure that you are adequately recognizing and rewarding individual and team achievements as they relate to shared values and goals. Make sure those rewardsrespect individualism and include choice. This will increase employees’ sense of fairness, purpose, recognition, belonging, and choice.
“A man who trusts nobody is apt to be the kind of man nobody trusts.” - Harold MacmillanAs I look at the list, I agree with all of the statements. I don't think it's a comprehensive recipe, but it's solid advice. The sequencing of the list jumps out at me as a tad off. I'm not sure Darcy is suggesting things be done in this order, but enumeration implies some form of priority or sequence. Assuming there is a priority to this list, I'd put strong company values first, followed by shifting focus from hierarchy to community. These two are the foundation of the remaining three items.
I encourage you to read Darcy's article. And please share your thoughts by commenting on this post.
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
This weekend I was forced to throw away a cardboard box. So what, I hear you think and I agree, but it being Sunday and me being in a hazy reflective Sunday afternoon state of mind (nono, no alcohol yet) and the box being the specific cardboard box it is (or rather was), I started thinking of the box’s significance for the future.
This is a picture of the cardboard box in question in it’s final state just before it got thrown into the recycler.
As you can see it’s got a large sticker saying ‘Oracle’ above the word ‘KABELS’ written in my clunky handwriting. The word kabels doesn’t really matter, it just indicates the box was used to hold various lengths of electrical wire. Next to the Oracle sticker and the kabels text you’ll see a partially torn label from ‘Donelly Documentation Services’ in Ireland. It is in fact the box that was used to ship my very first set of Oracle manuals (for release 6 of the Database and probably 3.0 of Forms and more contemporary tools) in April 1992. Since that time the box used to hold manuals for consecutive releases of Oracle products stored in the trunk of my car. I used to take them with me to customers on various assignments.
Later I left Oracle and the box was used in two removals (it was of remarkably sturdy material) and ended in my garage holding bits and pieces of electrical wire.
Last Sunday I dragged it of a shelf and finally it’s corners tore spilling cables all over me and the garage floor. Exit box.
This is getting into a long winded intro, I know but there is an interesting similarity between the box and the changes in the tools I use in my professional life. After starting as an Oracle specialist I worked on Java software which became Oracle software later of course. Last Sunday I realized I was writing Java-ish software again for the first time in about a year. Android, but still.
I haven’t been using any of the software I grew up with for quite a while now. Relational databases are being replaced by key-value stores and even flat files. JEE servers changed into Spray and Akka. Scala and functional and reactive programming constructs rather than object oriented Java and its bolted-on lambda extensions. Angular-JS instead of, hey wait a minute, that looks like a fat client all over again (wondering what’s going to happen to it). Server software I work with is easy to install, unpacking a zip file instead of 500+ pages of manual guaranteed only on an outdated Linux version. Modern software runs on simple Linux boxes instead of high end hardware with 7 digit price tags. New and innovative solutions replace software with slow release cycles. Open source is definitely leading the industry.
I wonder, does the end of the box forebode the end of a whole class of software? And like the cardboard box, will some bits and pieces come back in other products? I’m just hoping that it won’t take 22 years to get rid of the last generation of software.
I am a big advocate of each team having a public impediment list. Elsewhere I describe that in more detail, and some issues with it. The key thing: the main purpose of the list is to enable us to fix the ‘best’ impediment faster. We don’t just have a list to assure we do NOTHING.
In the recent course in Charleston they identified these impediments. You may or may not agree. There may be duplicates (maybe a rough indicator of greater impact). Maybe some are not clear to the reader, but only to the writer or that Team. The order is random.
We hope this list makes your Team more creative in identifying its ‘best’ impediments.
- Small group supporting sustaining work
- Lack of experience (skill set)
- Knowledge transfer
- Automated build-test / quality
- Requirements traceability
- Loading radios [To test the functionality of the software in the radios]
- Schedule tight
- Undefined goals
- Inexperienced people
- Shifting priorities
- Hiring people
- Establishing a team
- Unresponsive vendors (external)
- Issue with external system not in our control
- Moving timeline, target date
- Lack of ownership from product owner
- Changing scope
- Team concept
- Work distribution
- Lack of knowledge
- Inaccurate information
- No mitigation strategy [for risks, I think]
- Lack of buy-in
- No planning
- Inexperienced people
- Insufficient client management
- Not understanding client’s true needs
- Inadequate skills
- Changing personnel
- Over-committed [given too much work, I think]
- Don’t understand process
- Team not on same page
- Lack of pre-plan
- Lack of ownership [by team, I think]
- Adequate training (lack of)
- Weak company management
- Failure to commit
- Weak PM [in Scrum terms, I might say weak SM -- depends what he/she meant by PM]
- Changing goals, moving target
- Lack of resources, HW, SW
- Weak IT
- Risk mis-management
- Failure to communicate
- Do not understand goals
- Lack of teamwork
- No support
- Time Zones
- Change of vision
- Org not ready for change
- Scope creep
- Unrealistic deadlines
- Mean team members
- Moving timetable
- Lack of experience
- Under budget
- Poor stakeholder management
- Over budget
- Lack of leadership
- Unavailable team members
- No requirements
- Changing requirements
- Ins budget [Insufficient budget, I think]
- Bad estimates
- Lack ofparticipation
- Missed deliverables
- Poor attitudes
- Not enough tech knowledge
- Poor communication
- Product failure [one might need to identify the root causes here]
- Non compliant
- No gate reviews [In Scrum, each Sprint is a kind of 'gate review' -- but not sure this would be enough for the person who raised this concern]
- Unrealistic scope
- Lack of commit
- Employee no shows
- Insufficient time allotment
- No leadership [person started with 'A lack...' and crossed that out]
- Creeping scope
- Change of scope
- Team incompetent [for this work??]
- No enough people
- Inadequate schedule
- Lack of planning
To get this list, I asked two questions, one early and one later:
1. What are the root causes of failure in most projects?
2. We need to double velocity in 6 months, and we have to change radically. What do we have to change to get the velocity (productivity) to double?
This may explain some of the duplicates.
Coaches for Agile teams and organizations is a growing profession. I’ve been coaching for a long time, and I’ve used/invented/learned-about many different techniques or interventions for coaching in the context of Agile teams. I have recently started a Wiki to capture some of this information. (Originally, I was hoping to write a book, but I don’t have the time to do it on my own or even to coordinate a multi-author effort.) This is an open invitation to participate in the wiki. I won’t make it fully open (like wikipedia), instead, it will be by invitation. Connect with me on LinkedIn and mention you would like to contribute, and I will set you up with an account… and then you can go nuts If there end up being several contributors, I’ll make a block on the front page for links to contributors and/or their organizations.
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.
Through an interesting turn of events, I was given an opportunity to place an ad for my Backbone Plugins eBook in a very prominent web development newsletter – one that has 175,000 subscribers. Needless to say, I jumped at the chance. Unfortunately, the chance did not reciprocate the jumping. It was more of a laughing and pointing. In fact, it kicked me in the stomach while it was laughing at me crying under my desk. I seriously wasted this opportunity… and honestly, I’m not sure I got any really valuable lessons out of it. But I did get a few things from it. Hopefully they’ll be meaningful and helpful to someone else.The Ad
I spent several hours crafting the ad image, getting feedback, redesigning it and using my existing marketing material as the basis for the ad. After tweaking it to what I thought was perfection, this is the ad I ran with:
As I mentioned before, the email newsletter that this ad was placed in has 175,000 subscribers. That’s a lot of eye balls to put on this ad. The list in question also has a touted click rate for ads of anywhere from 0.5% to 2.5%. That’s pretty good, from what I hear. And I figured that if I could hit 1% click rate, I would get 1,750 views on my landing page. If my previous conversion rate of near 6% would hold for sales once people were on the page, I would have roughly 100 sales. At $22 per sale (after fees), that would be a nice little income of over $2K. This sounded like a no-brainer for me.
What I actually got was … basically nothing. My has had 169 unique visitors today. This is up by about 40 from the previous day, when I did not have this ad in front of 175,000 people. It’s about double my usual traffic, too. But this number did not translate well from what I hoped was going to be up to 1,750 views.
The conversion rate for this traffic was 5 sales (1 of which happened well before the ad ran) to 169 unique visitors… that’s about 2.95% conversion rate. This isn’t the 6% that I held for February but this is a good conversion rate. If I could hold steady at around 3% conversions and increase my traffic by 10 times, I would be golden. But my traffic isn’t 10x this. It’s 169 unique visitors.
So I come away from the day with next to no traffic increase, and a conversion rate that isn’t even a statistical bump – it’s within my site’s normal course of sales to have as many as 7 sales in one day. Today was only 5 sales, total.
I call this a failure. I didn’t get a bump in traffic. I didn’t get a bump in sales. I expected more. I don’t know what I did wrong, but I have some ideas. Hopefully these ideas will help others avoid the same failure I had.Lesson: Be Careful With % Click Numbers
When a website or newsletter tells you that they get a % range of clicks for ads, you should assume that you’ll be on the low end. Do the calculations for cost vs potential payback based on the the low end. In my case, the stated low end was 0.5% click through. In reality, I think I got less than 0.05% click through. Even if I had received 0.5% click through, I would have received a significant boost in my site’s traffic. I did not receive even the low end of traffic. The click %’s were completely off for me, perhaps because of other problems.Lesson: Target The Specific Audience
One of the failures I see in my ad is that I was still focused on my target audience: developers. The newsletter in question may have developers on it, but it most likely has a broader, more generalized collection of people interested in the web and websites. The issue that I appeared in, for example, dealt with a wide variety of topics surrounding websites – from development, to ideas and even a website about weather information. It was clearly not targeted at developers, which is what my ad was targeted toward.Lesson: More Eyes Does Not Mean More Clicks
This goes back to the target audience, again. Just because you get your ad in front of 175,000 potential eyes, doesn’t mean you’ll get a spike in traffic. If you’re advertising squirt bottles full of ketchup to an upper class group of people that only wear pure white clothing… well, good luck. Having more eyes on your ad doesn’t always translate in to more clicks and traffic. Understanding the target audience and being able to speak to their needs is critical.Lesson: Prominent Placement Doesn’t Mean Anything
I was the first ad in the newsletter… the first of 4. This should be the prime spot for an ad, as far as I know. It’s the first ad that people see. But once again, if your ad isn’t targeted at your specific audience, having prominent placement doesn’t mean anything.Lesson: Without Context, Great Advice Is Just Advice
I spoke with several people who have a strong history of selling and advertising, and got feedback from them on my ad design. Everyone gave me great feedback and suggestions to improve what I had. In the end, I had at least one person that I respect a lot say it looked very professional and they expected great results from the ad. Without understanding the complete context of the target audience, even the best advice for ads can fall flat.
I don’t know if it was just the target audience problem, but the ad that everyone said was good ended up being a failure. Perhaps the call to action was wrong. Maybe I should have stuck with my original call to action. Perhaps the wording is incorrect for the target audience. Am I speaking the language of the reader and pointing out something they care about? Or am I simply spouting what I believe is important? These questions are hard to answer without doing more research on the audience and then doing A/B testing on ad variations – none of which I can do.Lesson: Fail With Friends
I’m lucky in that I have a group of close friends in a mastermind group. Both John Sonmez and Josh Earl were extremely supportive in my effort to build the ad and in my struggle to not be depressed about the poor performance of the ad. If you’re going to experiment and face failures like this, you need to have a strong support network.Final Lesson: Advertising Is Hard
There’s no two ways about it. It’s just plain hard. You might think you have a magic formula, or at least enough feedback to help you find the right spot to be. But when it comes down to the day of execution, all of the formula in the world might not mean a hill of beans. Advertising is a horribly difficult, frustrating experience. Be prepared for failure. Find ways to fail fast, cheap and with measurable results.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
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.
The ideas below reflect the discussions we (Maaret Pyhajärvi, Martin von Weissenberg, Vasco Duarte) have had while reflecting on our Visions for Agile Finland. We hope these ideas are discussed and developed within the Agile community in Finland, and end up in a set of actions for the Agile Finland Executive Committee 2014-2015. We also commit to present ourselves as candidates for the Agile Finland executive committee in the next Annual Fannual meeting and are open to you joining our group to be part of the next executive committee.
If you share our ideas, get in touch and join us for the Agile Finland board. If you don’t share our ideas, please join the debate! Publish your ideas, volunteer for the next Agile Finland board on your own or as part of our list. Our goal is to spark debate and ensure we will have a strong group of committed individuals to continue the work that we feel Agile Finland needs to complete.Read our ideas below, and let us know what you think. Community servicesAgile Finland needs to take a role in the progress of software industry in Finland. One way in which we can do that is by cooperating more closely with the companies that identify themselves as Agile companies, both consulting and product/service production.
We want Agile Finland to be a platform for all members of the Finnish Agile Community, be they individuals or other organizations (for profit or not). As an example of this cooperation, we want to establish a yearly market research process financed by Agile Finland that would deliver a yearly “state of Agile in Finland report” and distribute it to the companies in the Agile community as well as to the media and individual Agile Finland members. This report can include topics such as:
- Market size for Agile contracts
- Market size for Agile software development (revenues, number of jobs, etc.)
- Key trends from the Agile market in Finland (topics of interest, business models, etc.)
Over the past years, conferences (especially Scan Agile) have been a major funding component for Agile Finland. We want to propose some changes in this respect. We recognize that it is today unclear for Sponsors to know which events to participate in as sponsors. If you support Tampere Goes Agile does it make sense to support another major conference like Scan Agile? How about conferences that happen at similar times? Which one to choose?
We find these choices confuse sponsors and do not adequately serve our present Agile Finland members either. Therefore we propose a change in model for 2014-2015. We propose that companies interested in sponsoring Agile Finland be able to sponsor the whole year of events (several major events are held by Agile Finland every year) and be allowed to choose which ones they participate in. For example, if Company A purchases a yearly sponsorship from Agile Finland they could be features in Scan Agile, Tampere Goes Agile and local events that will happen during the year.
Alternatively, companies could still purchase sponsorship packages for specific events just like they did until now.
Additionally we want to propose a change in the Agile Finland bylaws to allow corporate membership. This membership would allow companies to have access to services such as market research, recruiting communication and other services that Agile Finland may want to develop in support of the Agile business community.Sponsoring local events
Agile Finland wants to support local Agile communities around Finland, therefore we will commit a minimum amount of money to self-organized community events. All that is needed is a request to the board and the funding will be approved provided we stay within the agreed limit. If you have an idea to support your local community we want to help you without a long wait for either practical or financial support. We want to help local communities get more active, and our support (advertising and financial support) will make it easier.Developing a future for the Finnish software industry
In 2014-2015 we want to start what we hope will become a trend for the future of our industry. We want to support events designed to support future professionals get familiar with what it means to work in a software organization. For that we will organize events with school-age children on topics such as what the “maker” community already supports all over the world. Creating projects that young Agilists could work on, from concept to execution. But we will also try to grow partnerships with student organizations, universities and companies to have a mentorship program started to help integrate students in the software industry easily.Major events for 2014-2015
Events such as Turku Agile Day (which we want to support actively), Tampere Goes Agile and Scan Agile are events that attract a large audience and spreads knowledge and awareness of Agile within our community, but also helps establish strong links to other communities.
We want to continue to host and these events but also recognize that a voluntary-only approach has risks that must be tackled. We will consider how to support these events on a case-by-case basis and will work to make their organization a sustainable project that does not require heroic efforts from some of our members every year.
We recognize that each event has their own identity and we want to support that diversity.As first actions we will:
- Reach out to the Turku Agile Day group and learn how we can further support their goals;
- Help find voluntaries to help host Tampere Goes Agile and Scan Agile;
- Work with each event to make sure they receive the support needed, including professional services for event organization, design, web-hosting, etc.
Do you want to help shape the next year for Agile Finland? Participate by sharing this blog, commenting or tweeting/blogging about the topic yourself! Be active, let's make Agile Finland even better!
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. ?
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]