One of the primary goals of annual planning is to translate aspirational strategic plans into realistic execution plans. Sadly, rather than delivering plans we can all feel good about and believe in, too often it leaves us depressed about the work ahead of us. This article shares five practical principles to remove the emotions associated with annual planning.
We hope you enjoy this holiday poem on Sprint Planning. It was an early holiday gift to the Agile Management Blog from Daniel Gullo, owner/principal of Apple Brook Consulting. Thanks, Daniel!
‘Twas the night before Sprint Planning, and all through the Team
Not a member was worried about the upcoming theme.
The Stories were refined and the Backlog was set;
Poker had been played without a single bet.
Appropriately sized and estimates all sound;
Acceptance Criteria to establish firm ground.
The ScrumMaster and Product Owner had just finished a call,
To talk about ordering and a potential Sprint Goal.
The Retro had happened several days prior;
The Scrum Team had discussed how to move the bar higher.
Agreements were revised and the Definition of Done
Included more testing and other such fun.
The stakeholders were eager to see the new stuff:
“The product has value!! Perhaps we have enough??”
In the last Sprint Review, the Team had shone bright,
A shippable increment, a product in its own right.
Wouldn’t be long ‘til the Team would release,
Causing the customers’ delight to increase.
The CEO and the VPs were finally content,
The decision to be agile had caused no lament.
Developers are happy in practicing their trade
Testers are ecstatic they are no longer blamed.
And everyone has a chance to really collaborate
Without worrying about the build being late.
As dawn approached and meeting was nigh,
The Team members were up on an adrenaline high;
Excited to move forward and full of new hints,
The wonder of Scrum and working in Sprints.
“Is agile right for me?” you may be wondering,
As your organization continues with delivery blundering.
If your culture is ready to be focused on learning,
Agile will help you return to positive earning.
Get more info on sprint planning within VersionOne.
Have you been in a meeting lately where people were focused on their laptops, interrupting each other, distracted, or otherwise behaving badly? In Jean Tabaka’s “Leading Collaborative Meetings” class, Jean talks about the importance of working agreements to create the safety that makes productive dialogue possible.
When I see people facilitating meetings around here, there are some common working agreements that show up often:
- “One conversation at a time” helps people hear each other.
- “Electronics by exception” enables people to stay focused on the work rather than getting lost in their devices.
- “Start and end on time” is important if your discussions tend to run long.
But we also do a lot of large-scale meetings with 50, 100, or even 500 people working collaboratively on a plan. And at scale, some of these agreements don’t work as well. “One Conversation at a time” doesn’t make sense much of the time. With 500 people, some are going to come and go.
So here are some of the agreements we’ve experimented with when more than 100 people are trying to agree on a plan, along with how we explain the working agreement to the group.Aim for Good Enough
“With 300 people here, we’re trying to get to a reasonable degree of alignment. We’ll continue working on our plans throughout the release. When you’re engaging with the larger group, think about whether your issue needs to be discussed with everyone or whether it can be resolved with a smaller group. If we’re getting stuck, think about how a small group can work to bring back a recommendation to the larger group.”Be Back on Time
“Large group meetings are expensive. It’s really important to be here on time so we don’t have hundreds of people waiting for you. This matters a lot when we come back together at 4 pm today, and when we start tomorrow morning.”Raise Risks Early
“If you know of an important risk, raise it as early as you can. During the morning activity is your first chance; then during your breakouts you can also raise issues early. If you can resolve the issue today, that’s way better than making us stay late tomorrow.”Leave if You Need to Do Other Work
“We have so many people here, there’s a good chance something will come up that requires some of us to shift our focus. If you do need to do other work, please step out completely so that the rest of the group can focus.”
We’ve had some success with these, especially when the “regular” working agreements have already become the cultural norm. What working agreements do you use in large-scale planning meetings?
Learn how to lead productive, enjoyable, effective meetings. Sign up for Jean Tabaka’s “Leading Collaborative Meetings” class today.Alex Pukinskis
“Can I say on a personal note , since I came back from the AAD it has relit the fire in me , I can only thank you for providing the spark.” -Tony
An inspiring 2d w @TotherAlistair learning #AdvancedAgile from the 1 guy in the world capable of teaching it… Now time to repack my brain. – Tyson
“It was a great experience and definitly changed my mindset. Anyone doing scrum should take the class and get some “agile inspiration” :)” – KostaMove to the next stage by learning from one of the authors of the Agile Manifesto!
- Level: Intermediate and Advanced :
- This is the course for you if you have been doing agile development for 3-15 years, have read many of the books and are ready for a deep dive into what agile development is all about.
- This is the course for you if you have been doing agile development for 1-5 years and want to amp up your capabilities to the next level.
- This is not the course for you if you are a hot shot programmer or PM and want to strut your stuff.
- This is not the course for you if you are looking for an introduction to agile, basic of Scrum, CSM, or project management (attend instead the Fundamentals of Agile Development public course (discussion: Re: Agile Development Class with Crystal and Certified ScrumMaster)).
- This is a course for those who want to inquire and to get themselves ready for whatever comes next.
This is the advanced masterclass in agile development from industry guru Dr. Alistair Cockburn.The Center of Agile Advanced Masterclass with Dr. Alistair Cockburn
Modern “expert” agile practitioners have mastered the practices – but not why they work, not how to adjust practices to situations, not how to approach new and surprising situations, not how to apply agile practices to non-software projects, not how to incorporate results from other fields back to their own projects, not how to tailor the practices to different organizational cultures. This advanced course from industry guru Dr. Alistair Cockburn addresses those areas.
- In this discovery-filled course,
- Learn why agile works, in software or outside of it,
- Learn how to articulate and deal with the weaknesses in agile development,
- Test yourself and your partners with the Test-Driven Carpaccio exercise.
- Learn to reduce risk and maximize results by viewing design as a Knowledge Acquisition activity.
- Practice backing up your recommendations with solid theory, not just an appeal to authority,
- Learn how to plan and track larger, more complicated projects using Story Mapping or Blitz Planning (time permitting),
- . . . and most of all
- Come face-to-face with yourself, your strengths and your weaknesses, as you confront one situation after another with equally inquisitive classmates.
Bring along bring gnarly problems you have been challenged with and objections as to why agile can’t work in whatever context: We will work through those problems as a class, using the skills taught in the class.
This is not a course for the beginner or the faint of heart. Expect to do homework, expect to be put through your paces, expect to dialog and argue, have your beliefs challenged.
You need not prepare for the course, but you will get more from it if you have read Agile Software Development: The Cooperative Game and “The Seven Properties of Highly Successful Projects” from Crystal Clear: A Human-Powered Methodology for Small Teams prior to the start of class.
At the end of the course, walk away with a rich, robust set of tools for approaching your project and organizational situations.
Dr. Alistair Cockburn (pronounced Cō-burn) was voted one of the “All-Time Top 150 i-Technology Heroes” for his work in creating and steering Agile software development. He co-authored the Manifesto for Agile Software Development and the “Declaration of Interdependence,” created the first Agile Software Development Conference, co-founded the Agile Project Leadership Network, served on the board of the AgileAlliance, designed the Crystal family of agile methodologies, and co-founded the International Consortium for Agile. Three of his books have won Jolt awards and been listed in “The Top 100 Best Software Books of All Time”. He consistently receives high ratings for his presentations and courses. Much of his material is online at http://Alistair.Cockburn.us.What Students Wrote After Attending One of Alistair’s Master Classes: “Huge emotional learning about self.” -@ksteffe “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe ”#AdvancedAgile with @TotherAlistair is like walking in as an agile Jedi then some dude with pointy horns pulls a double ended light sabre.” – Todd “Inspiring, I will be going back into the cooperative game with a refreshed strategy and some new moves” – Kelsey ” Best part of the course: Learning how to ask questions without jumping to a solution” ” It was interesting to see how we forget important known stuff when we face a crisis” – Pavel ” THE forum to test every theory and stalk even the sacred cows of agile practice ” – Kim “I don’t care what they say, being with you is a pleasure.” – CM “Really great master class with @TotherAlistair” “Mind exploding like crazy.” “Definitely inspired to up my game!” “Ego obliterated, mind expanded, much to ponder after the masterclass. Thanks” “I had to call in sick the next day.” “Huge emotional learning about self.” -@ksteffe “I feel a lot better this time around after coming out of Alistair’s class. Learned a lot and my mind is clear” “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe “Alistair is the Chuck Norris of Use Cases. Applying use cases to the project life cycle has re-instilled my faith in project management.” “Alistair provided a non-intimidating environment to allow for mind stretching. I feel like I’ve been put through a mental wringer but all in a way that can only improve my value for my team.” –Nicole Hopkins “The deep level of experience Alistair brings to the training adds significant insight to the domain.” –Dave Pugmire “Excellent course… well worth the investment of time and money. I especially appreciated Alistair’s depth of knowledge and breadth of experience. I will be watching for other courses offered by him.” –Chuck Stoner “Course goes well beyond novice level in terms of cognitive complexity. Pushes into analytical/critical thinking skills.” –Cristina “I want my boss, my boss’s boss and my boss’s boss’s boss to take this course.” “I would certainly agree with Alistair’s characterization of what he does being the height of voodoo witchery and other eldritch practices, at least to the untrained eye. Stretching the metaphor even further I’d also say that some of those that he coaches are left with a feeling much like what I would imagine a visit to the voodoo shaman would engender – glad that he was there to help, but equally glad that he has taken his rum and chickens elsewhere.” –Jonathan “In 20+ years of attending courses in software development this has been the best course. Great balance of theory and lab (hands on) work.” –John W. Cooley “Fantastic course for practitioners who want to think about what they do and improve their teams. Cuts through the Agile hype to communicate deep insights and truly useful techniques.” – Kay Johansen “This course was simply amazing! Dr. Alistair Cockburn has one of the best minds period. I have so much to learn. This course should be mandatory for all project managers.” – J. K. “Excellent job of imparting knowledge without creating dogma.” – J.S. “Your teaching style/positioning as a methodologist fit exactly what I was looking for, not dogma but the base/broad thinking behind the practices” – Anastasia “Alistair combines the theory with practical experiences and exercises that reveals the hows and whys of agile.” – Richard Thomson “It is great to be able to tap into Alistair’s years of experience!” – Sean Landis “It was great to take this course from one of the acknowledged leaders in the field.” – Jeff Romine “Very enjoyable course. More please.” “Exceeded my expectations! Great class; excellent presenter!” “Alistair is a wonderful instructor! Very knowledgeable, easy to listen to, and funny!” – Anne Marie Kimberling It was awesome! It broke my head! – Maria Fernanda “OMG @TotherAlistair u broke me!! I am seeing holes in everything that we are doing. Hugh improvement opportunities!!” – Supriya “I wanted to be challenged – and I was not disappointed – participants got kicked out of their comfort zone before morning tea on day one, by lunchtime you knew there is no going back.” http://www.betterprojects.net/2014/03/advanced-agile-review.html “He set out to challenge all of our preconceptions about agile, deconstruct them, and then help to rebuild our understanding using different lenses he’s crafted from his deep and extensive experience. The result being, that people walked away with more insight, understanding and approaches with which to advance their own agility and those of the people around them.” http://www.tabar.com.au/advanced-agile
It seems to me that the text of this blog describes a more active engagement with a challenge than the title implies. More “Working towards arrival” than “Waiting for” it.
-by Seb Rose on 12/14/2014 at 11:35 PM
“I don’t know you in the distance. I only know you near me”
“I was shaking this morning as I was shaking now”
Are those yours?
They are beautiful
-by Gabriela Szulman on 12/15/2014 at 11:00 AM
Thank you, Gabriela. Those are special poems. They arrived at a unique moment, which I don’t expect to repeat.
An aspect of the “Release” concept the authors talk about in the book sounds a lot like Czikszentmihalyi’s “Flow.” Interesting book. Thanks for the tip.
-by Todd Webb on 12/16/2014 at 4:31 PM
“I don ‘t know you in the distance, I only know you near me”
“I am shaking this morning as I am shaking now”
Are those yours?
-by Gabriela Szulman on 12/15/2014 at 10:20 AM
Yes, thank you. Those were unique moments. I might hope that someone else finds similar moments. Alistair
You know that great feeling you get when you meet someone and instantly hit it off? You realize that you know people in common, feel like you could have endless conversations, and get excited about the same things. Over the past few months, that type of connection sparked the partnership we announced today between Rally and Code for America, the organization championing the civic-tech movement. Because of our shared mission and values, we’re combining our talents with technology to better communities nationwide.Bring on the Brigades
Furthering our missions. At Rally, we believe empowered people who can adapt to change and harness their collective creativity are essential for solving today’s big problems. We’re excited to further this mission and equip teams to innovate and thrive by sponsoring the Brigade program, a citizen-driven network of 4,500 volunteers. Working in partnership with municipal governments, nonprofits, and other civic groups, Brigade members use technology to address local problems or create new opportunities.
You can contribute your skills to the cause by joining a team, writing code, or even launching your own Brigade:
- Find a Brigade near you.
- Start coding today: the Civic Tech Issue Finder shows help wanted for open GitHub issues.
- Mark your calendar for the annual CodeAcross event, Feb 20-22 (in January, the website will show sites hosting an event).
- Really want to jump in? Watch the How To Start A Brigade video.
Sharing our talents and tools. In a world driven by software, Rally is convinced that Agile helps accelerate the pace of innovation to help people create products that users love. As a leader in building Agile teams, Rally is giving the Brigades open access to its renowned software tools to help improve team communications, coordination, and project management. We’re also helping the Brigades tap into the talent and expertise of our people to fully realize the benefits of being an Agile team — because working together faster, more efficiently, and more collaboratively to achieve better results will foster civic innovation that benefits everyone.
By working closely with the Brigades, Rally employees get to hone their skills in a different environment — a safe sandbox in which to explore, experiment, and practice. As a company, we’ll learn more about how disparate teams work and how we can use our tools and people to add value to the team experience.Investing in the Civic Tech Movement
Program funding. A year ago, we created the Rally For Impact Foundation with a 1% equity donation from our 2013 IPO. As part of our investment in Code for America, we are donating $50,000 (our largest grant award to date) to help fuel the growth and development of the Brigade network. When we set aside 1% of equity several years ago, we laid the groundwork for realizing our vision — extending our impact beyond our employees and customers to be a part of a global, growing movement of cooperative collaboration between citizens and their communities.
Goals for year one. In 2015, we’ll partner closely with a handful of Brigades. Rally employees will mentor each of these Brigades to help them apply Lean and Agile techniques to project creation, planning, and execution. Plus, in U.S. locations with Rally offices (namely Boulder and Denver Colo., and Raleigh, N.C.), we will create meaningful opportunities for employees to get directly involved — such as joining and mentoring Brigades, working on open GitHub issues, participating in the CodeAcross event, and hosting hackathons. In addition to software developers, the Brigade movement needs people with the skills necessary for a successful technology implementation, including project managers, designers, data analysts, marketers, community organizers, and subject matter experts.
Learning what Brigades need. During the first year of our partnership, we’ll explore ways in which Rally can best contribute to the Brigade movement from a product and people perspective. We know from experience working with hundreds of customers that technology development projects leveraging Lean and Agile practices help teams collaborate better and are more successful in bringing the right solution to the people who need it. We’re ready to mentor and train Brigade leaders and members in these practices, but first we need to understand how to apply them to grassroots, volunteer-driven teams in a way that can scale to eventually reach the entire Brigade network.
Agile toolkit for Brigades and beyond. In collaboration with the partner Brigades, we plan to use what we learn in 2015 to create an open-source toolkit for civic technology projects. The toolkit will be designed to help anyone learn and apply Lean and Agile techniques, methods, tips, templates, worksheets, and tools that will benefit them in their project work.Learn more
Code for America
- Code for America (website)
- Code for America: Building 21st Century Government (video)
- Coding a Better Government (TED Talk by Jennifer Pahlka, Founder and Executive Director)
- Where We’ve Been, Where We’re Going (Jennifer Pahlka’s Blog November 26, 2014)
- Brigade Program (website)
- Learn about the Code for America Brigade Program (video)
- Why Good Hackers Make Good Citizens (TED Talk by Catherine Bracy, Director of Community Organizing)
- Brigade project examples: Balance, CyclePhilly, Soft Story, Open Disclosure Oakland, Flu Shot Finder, US Cities Open Data Census
“Usually we try a scene or a moment so many different ways that the right choice makes itself known. And everybody in the room know what that right choice is. We work until we find that”.
— (Abigail Adams, director of People’s Light and Theatre Company, “Artful Making” p. 19)
That moment, I call Arrival.
(What a great title for what this blog post is about!)
“Failure isn’t the right idea. In rehearsal, the iterations all interact with each other. The current run-through provides the main material for the next run-through. Each trial is a necessary step on the way to what’s good and essential to the final success. To call an essential step toward success a failure merely tortures language. What’s more, the word “failure” applied to routine work could poison the growth of Ensemble, a quality of group work essential to rehearsal, and to artful making.” — (p xxviii “Artful Making” Rob Austin & Lee Devin)
What is Arrival?
“When Stella burst into tears … even the director had to get a grip. Something big was happening. Something beyond work came into the room. The stage manager called, “And, lights.” There followed a moment of hush, a deep and happy silence of accomplishment. Then, from someone in a far corner of the room came … the flat, empty drawl of NASAspeak: “Ahhh, Houston? We have play.” ” (“Artful Making”, p.13)Arrival: Not Experiment, Not Discovery
“Not Quite Experiment, Not Quite Discovery” _(“Artful Making”, p.22) :
“Scientific experiments look for causal relationships … ‘Discover’ suggests there is a right choice waiting to be found.”
so what is it, then?
“the importance of individuals’ efforts to release themselves from restraining preconceptions and inhibiting circumstances; the intensity and interdependency of these collaborations; the understanding of “wrong” choices as advances rather than setbacks; the sense of the emerging product as something better and more interesting than anything a single person could have preconceived, greater than the sum of it’s parts; an unpredictable result that in retrospect seems investable.” (“Artful Making”, p.14)
“Touch a hot stove and burn your hand… touch it again and burn your hand again… same injury, no new information. ... you may need to make the same mistake many times on the way to an innovative leap. Burning your hand is a small price to pay for a good idea.” (“Artful Making”, p. xxiii)
“every choice an actor makes enters the play and, in some form other, remains there. ... experience becomes the material that future choices are made of. ... People are people, and they don’t have Delete keys. ... Inclusion of past actions into the materials of creation is the force that drives emergence” (“Artful Making”, p. 21)
What he calls “emergence” there, I call Arrival here.Communication is touching into shared experience
There is a little fake being inside us who demands too much attention: the little ‘i’, the little voice from our prefrontal cortex, commandeering our vocal cords to make sounds to our heads that sound like they are our voices speaking. Except the little ‘i’, utilizing only the vocal apparatus, denies external access to the many parts of our brain and bodies that also are looking for expression. Our minds are full of ideas we can’t know about as long as we listen to ourselves.
We have to act.
As we act, interact, act by accident (tripping over a bump), act in accidents (different modalities of expression take differing lengths of time to reach the outside world, creating accidents of timing between different parts of our bodies), we do things the little ‘i’ inside our minds did not have any idea existed. We create new realities, new moments of experience. Shared experiences, if we are with a group.
Each act, action, enters our shared experience, becomes a building block for future actions.
“by running-through many times with variations and accidents, we build new shared experiences, new building blocks for action and for communication.” (“Artful Making”)
If one of us burns his/her hand on a stove several times in a row and does not learn, that by itself becomes a ‘meme’ for the person, for the group. Thus, “the current run-through provides the main material for the next run-through.”
The moment of arrival is when something shows up that we recognize as being an advance.
And so we wait for it. We act, we experiment, we stumble, we shout, we make nonsense, we do the same dumb thing 10 times in a row. We are waiting.
And it arrives.Arrival
I am using the word ”arrival” to name that thing that was never there in the first place, but which we suspect can be there, but we can’t find it, we can’t hunt for it, we can’t discover it, we can’t invent it. We have to wait for it.
Arrival happens to poets, to musicians, to comedy writing groups, to theater groups, to programmers and designers discussing an idea together.Constructing an Arrival
“Artful Making” (Austin & Devin) describes constructing an arrival as well as I have ever seen (the description of working on the play Streetcar Named Desire.) They describe theater as a process that generates arrival moments reliably, although no one knows when the arrival will arrive.
The only way to get the arrival to arrive is to play, to experiment, to push things past their boundaries. To do dumb things, crazy things, the same thing over and over; and wait for some hitherto quiet part of someone’s being to express itself in some way that has not been seen before.
As a person in a design group, I watched as one person mis-wrote what someone said, and someone mis-read what was written, and what he said was just what the group needed to hear. It was the winning idea. I have often seen designers discuss an idea at a whiteboard, and every time one person made a comment or drew, another person said, “But in that case…” and made a new, great observation. In minutes, the group designed something that none of them could have designed alone.You don’t say Sorry in hackey sack
Hard for me to not say “sorry” when I drop the hackey sack. But I had to learn it. It’s part of hackey sack to drop the hacky sack. You can’t have a group saying “sorry” every time they drop the sack.
You don’t say “sorry” when making a fault in an improvisational dance. You might restart, or you might continue, but “sorry” isn’t in the game.
Similarly, in constructing an arrival, you don’t say “sorry” for each version that doesn’t produce an arrival. You just add to the stack of available material and keep going.You can say Thanks and High-Five
I wish to thank Diego Fontdevila, who pushed “Artful Making” under my nose years after I had first seen it, but just at the moment when I could read certain sentences in it. Thanks, Lee Devin, for pushing Rob Austin about the topic of “failure”, and to the two of them for getting the book published. Just these pages alone changed my life.
For my part, I immediately put this new knowledge of Arrival to use. I dance a lot, but am terrified of making mistakes with a partner on the dance floor. Just after reading this book, I went to a free-improvisation tango class, and although still sweating, stopped saying “sorry” and only froze once on the dance floor, viewing now each faulty move as just a brick in my construction of an Arrival for better tango dancing. My partner, too, (since we were taking turns leading in this free-form tango class), had to learn to not say “sorry” with faulty moves, but to replay or just continue after each one. We do, however, high-five after great accidents and arrivals.
In this guest post by Jeff Sutherland, co-creator of Scrum and CEO of Scrum, Inc., you will learn five reasons why 49% of agile projects fail – and how you can avoid it.
My book, “Scrum: The Art of Doing Twice the Work in Half the Time,” was published in October. Over the last six weeks, I’ve been touring the U.S. and Europe telling the story of all the influences that culminated in the creation of the first Scrum team over 20 years ago. No matter where I go, people ask me what the secret is to running a good Scrum. The secret sauce of running a great Scrum Team is Getting to Done!
There is a lot of “bad agile” out there. According to Jim Johnson at The Standish Group, 49% of agile projects fail. Why? Because people don’t grasp the essence of what it means to be agile. It requires a fundamental shift in thinking. The second value of the Agile Manifesto is quite clear: Working software over comprehensive documentation. That means that at the end of each and every Sprint you have potentially shippable increments that work!
Working software is key because it is the catalyst for one of the most important aspects of the Scrum Framework: feedback. If you don’t have working software at the end of the sprint, stakeholders can’t use it during the Sprint Review and, as a result, can’t give the Product Owner and team the feedback that will allow the team to develop the product into the customer’s sweet spot.
The secret to working software is complete testing inside the Sprint. If your agile testing practices aren’t tip-top, your teams are probably struggling, your customers are probably frustrated, and you most likely don’t know when the product will ship.
Five Causes of Team Failures
1. Poor definition of DONE
2. Stories not READY
3. Dysfunctional Leadership
4. Technical Debt
5. Ineffective coaching
A rigorous definition of Done includes working tested product at the end of the Sprint. Teams must work together to refine their definitions of Done. Product Owners have to stop accepting Stories that don’t meet these criteria.
Good definitions of Ready and Done are two levers that produce successful Sprints. Stories don’t magically become Ready; they need to be clarified and granulated. Acceptance tests need to be embedded. This takes time and attention from the Team.
A leadership team that sees the benefits of going agile, but hasn’t engaged enough to shift their mindset, is a recipe for disaster. Scrum works because it allows capable workers to self-organize and determine how best to accomplish their goals. If management maintains a command-and-control mindset, a Scrum implementation will fail.
In an agile context, managers become leaders. They are tasked with setting transcendent goals for the organization, supporting the teams and removing organizational impediments. They need to determine what Scrum metrics would best bring transparency to the processes so they can hold the Product Owners responsible for value delivery and ScrumMasters responsible for velocity.
Technical debt needs to be stopped in its tracks. The discipline of having clean code every day is essential, as is completing all testing within the Sprint. Then the historic technical debt can be reduced piece by piece.
When implementing an organizational change, companies are pretty good about educating their employees but they fail to provide them with support they need to succeed. The most successful implementations not only get their workers certified but also bring in outside agile training and consulting services help to launch the teams.
A team launch includes an expert coach who helps develop the first iteration of the Product Backlog, helps the teams define what it means for a story to be both ready and done, and leads them through all the Scrum ceremonies at least once. Ideally, the coach returns periodically to fine-tune the teams’ work and take them to the next level.
Systematically focusing on remediating these issues will consistently produce high performing teams with 200% to 400% improvement in production.
Failure to focus on them will add yet another team to the 49% of teams that are “Bad Agile,” leading to unhappy customers, lost revenue, and lower stock prices.
For more information, grab the recording of my recent AgileLIVE webinar: “Getting to Done – The Power of Scrum.”
Probably one of the most frustrating roles a manager has to master is how to know the true status of work being performed. To a developer, completing 80 percent of the work may be good enough, but is it even close to being really done? Masha Nehme shows techniques you can use to verify task completion.
Everyone knows you need more than a whiteboard and stickies to practice Agile at scale. But the tool you use isn’t the only thing that matters: as Dean has said, “A fool with a tool is still a fool.”
The true value of Agile comes at scale, where it delivers benefits more broadly across your organization. Imagine how improved time to market, reduced development costs, and higher quality software will impact the goals your entire organization is trying to achieve.
Research studies have shown that, on average, Agile methods yield 470% better ROI than traditional waterfall methods. This kind of return means investing in scaled Agile, yet this is exactly where many people fall down. Projects and programs aligned to an organization’s strategy are successfully completed at nearly twice the rate of those that aren’t aligned, yet this kind of alignment doesn’t typically happen with stickies and a whiteboard.
So: how do you execute a program that’s aligned with business needs and customer value? How do you connect thousands of user stories, hundreds of features, and dozens of epics? How do you give everyone visibility so they can operate with velocity?
You need a simplified system view.
Check out these short videos with Scaled Agile Institute’s Dean Leffingwell and Rally VP of Product Management, Ryan Polk, to find out how simplified system views help people do the right work: fast, and at scale.Steve Wolfe
As agile development has erupted over the software landscape, its core philosophy often has been neglected as organizations hurry to implement cherry-picked practices in the name of pragmatism. By avoiding these five common pitfalls, companies can better realize the true benefits of agile: high productivity, great software quality, and happy customers.