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.
Software development on anything more than a pet projects is a collaborative activity. To enable a group of developers to made any headway, some details inevitably need to be hammered out. However, you probably find that getting agreement within a group of opinionated developers can be difficult. Most software developers haven't had training in "soft skills" and you may find it hard to know where to start.
Here are some pointers to areas that you might want to explore beyond the realm of programming languages, methods and frameworks.
Facilitation is all about making conversations easier but even with a clear meeting purpose and agenda, you may find meetings can go around in circles without reaching consensus. To understand some approaches to making group decisions I recommend "Facilitator's Guide to Participatory Decision-Making" which introduces decision making rules. You can also get affordable hands-on training in facilitation from non-profit ICA-UK on Group Facilitation Methods.
Another thing you can do to help meeting participants is to create visible agendas and capture points being discussed concisely. If you want to build more confidence with writing neatly on flipcharts and whiteboards, seek out a course in graphic facilitation where you can pick up tips and practice with other budding facilitators. To improve how you illustrate system dynamics in group discussions, start to practice drawing Diagrams of Effects. Peter Senge's book "The Fifth Discipline" has a an excellent introduction to Systems Thinking and an handy set of system archetypes that you can use in different situations.
There's an old joke: What is the difference between a Methodologist and a Terrorist? You can negotiate with a terrorist! When discussions get heated, it's handy to know a little bit about negotiation techniques. The Harvard Negotiation Project have put out a few paperbacks and I recommend "Getting Past No: Negotiating With Difficult People" by Fisher and Ury. Another easy read around building trust is "The Trusted Advisor" by Maister, Green and Galford.
Lastly remember that we can improve communication in our teams by starting with ourselves and how we express our own opinions. A good place to start is "Nonviolent Communication" by Marshall Rosenberg. An older book that's worth getting hold of to get a different perspective on the way you share feedback is "The Art of Giving Feedback" by Charles Seashore and Gerald Weinberg.
I hope these resources help you in situations where you need to go outside your comfort zone. Please do let me know if you have other recommended reading to share that goes beyond coding.
So needing to have this conversation today, I had the time to do a search for some help. And I found this wonderful article and video with a voice over explanation.
Business Benefits of Software Release in Multiple Increments
And there is an interactive Wolfram graphic you can play with yourself.
Now with this link and the video explanation (done with a german accent I think, gives it real authority) - I can solve the problem of coming to that shared understanding.
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
I once worked in an organization where the senior managers thought they should motivate us, the team members. They decided to have a team competition, complete with prizes.
I was working on a difficult software problem with a colleague on another team. We both needed to jointly design our pieces of the product to make the entire product work.
After management announced the competition, he didn’t want to work with me. Why? There was prize money, worth hundreds of dollars to each person. He had a mortgage and three kids. That money made a big difference to him. I was still single. I would have stuck that money into either my savings or retirement fund, after buying something nice for myself.
Management motivated us, alright. But not to collaborate. They motivated us to stop working together. They motivated us to compete.
Our progress stopped.
My boss wanted to know what happened. I explained. I couldn’t fault my colleague. He wanted the money. It made a big difference for him. I would have appreciated the money, but not nearly as much as he would have. (Later, when I was paying for childcare, I understood how much of a difference that money made.)
I then had this conversation with my boss, ranting and raving the entire time:
“Look, do you want the best product or the best competition?”
“You can’t have both. You can have a great product or you can have a great competition. Choose. Because once you put money on the table, where only one team gets the money, we won’t collaborate anymore.”
My boss got that “aha” look on his face. “Hold that thought,” he said.
The next day, management changed the competition. Now, it was about the teams who worked together to create the best product, not the one team who had the best idea. Still not so good, because all the teams on the program needed to collaborate. But better.
When I had my one-on-one with my boss, I explained that all the teams needed to collaborate. Were they really going to pay everyone a bonus?
My boss paled. They had not thought this through. “I’d better make sure we have the funds, right?”
People don’t work just for money. You need to pay people a reasonable salary. Remember what Dan Pink says in Drive: The Surprising Truth About What Motivates Us. People work for autonomy, mastery, and purpose. If you exchange the social contract of working for autonomy, mastery, and purpose for money, you’d better pay enough money. You also better repeat that money the next time. And, the next time. And, the next time.
That’s the topic of this month’s management myth: Management Myth 35: Friendly Competition Is Constructive.
Software product development is a team activity, full of learning. As soon as you make it a competition, you lose on the teamwork. You lose the learning. Nobody wins. There is no such thing as “friendly” competition.
Instead, if you go for collaboration, you can win.
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
“Only one room
Only one way
Key is alive
Leave or stay"
Spoiler Alert --- some puzzles are solved below.
Collected Items ————paper scraplamp shadescrewdrivertesla bookUSB cord
Book Shelf - opens Screwdriver-------------------------------------Aristotle 384 BCERoger Bacon 1214 - 1292Leonardo Da Vinci 1452 - 1519Copernicus 1473 - 1543Galileo 1564 - 1642Newton 1642 - 1727Faraday 1791 - 1867Tesla 1856- 1943Alan Turing 1912 - 1954Stephen Hawking 1942
3 Stars - 5 points; ball on one point - 1 missing star; color of stars & books may signify the overlap of authors livesshark - pinguen - robot - got a USB cord in drawer(^^^) <(“) :|]
Bird - Dog - Elephant - Dolphin (brown yellow gray blue)A-Z 4-charblue red green 3 colors0-9 7 numbers4 greek letters - Theta, Sigma, Psi, OmegaTh, S, Ps, O9, 200, 700, 800
Picture of sheep man dog house trees clouds
by Egidio Graziani6 places (sheep, man, dog, house, tree, cloud)alphabetical order (cloud, dog, house, man, sheep, tree)order in picture left to right, eye flowing, front to back
buttons rotate in this order: cloud, sheep, dog, tree, man, house....
Table with Globe - gave a board with numbers (1-6)golf ball micro phone oscar statue W7 letters A-Zphonic alphabet Golf, Mic, Oscar GMOW GMO over Whiskey
Globe - six symbols
mirror over 4 drawer chestdrawer 1 top 8 point double ring w 4 push buttonsdrawer 2 3 blocks, 7 bundle, CBA, dart board 4 digitsdrawer 3 4 x 4 buttonsdrawer 4 4 x 4 buttons labeled ABCD 1,2,3,4 (Nice Room)
left side of bed clock with one hand000 000 00dial lock
above bed - picture of man and sheep (moves left right up down) center above bed
right of bedbox 9 box form letters two buttons
5 x 7 white gray black buttons on boxempty shelfbox with cyan red yellow triangle
dart board score = 172triple 18 double 15triple 16double 14twelve
8 segment clock with 3 hands 3:5:7 = 3/8 : 5/8 : 7/8big hand on 3med hand on 5small hand on 7
Largely learned nothing... except there is a really good cheat site: AppUnwrapper
Yeah, OK, I used a few of the cheats - but that's not a lot of fun...
Oh - and many of the puzzles have additional clues or items to pick up once opened. These items/clues are not visible until the lock is opened. For example a clue written on the back of the door.
I have two games running. So I took the opportunity to run a few experiments.
I had the Globe open in game A. In the second game, B, I keyed in the sequence of buttons for the Globe but it didn't open. Then I went over to the picture on the sheep, man and dog and applied the number overlay - POP! the Globe opened. What does this tell us? That locks are turned off by default and actions must turn the locks on. Such as the Globe, which was turned on by the number overlay being applied to the painting.
So... off to solve a 4 equation; 4 variable problem.
The bottom drawer (right of bed):
1) 48 x + 88 y + 2 z + 7 a = 86
2) 55 x + 4 y + 71 z + 86 a = 23
3) 6 x + 87 y + 28 z + 88 a = 4
4) 3 x + 26 y + 81 z + 74 a = ?
OPPS that didn't work out
CBA code is solved by hint
2a + c = 113
a + 2b = 93
b + 2c = 61
a = 47; b = 23; c = 19 --> 192347 = CBA
Agile is about people, both the people doing the work ("People and Interactions over Process and Tools") and the beneficiaries of the work ("Our highest priority is to satisfy the customer through early and continuous delivery...."). I believe people's own experience makes the most convincing arguments.
So I start by asking the people involved what has worked for them in the past. I ask them to remember their best projects and share the stories of those projects with other people in the room. (See Remembering Heaven for a description of how I do it). After hearing everyone's best projects and identifying the most promising role models for moving forward, we reflect on the patterns that made those projects successful.
Most people are not currently working on their best project ever. In fact, usually only about 10% of the people in the room are currently working on a great project. Very often no one at all is currently working on their best project ever. (I have seen numbers as high as 50%, but the difference between 10% and the higher score has always been a group doing Scrum!)
Would you like to be working now on your best project ever? Most people would! Could you agree to implement the patterns which made your best projects so awesome? Most people are willing to do that.
Wait! What exactly have we agreed to? Well at this point, I start to introduce Scrum (my favorite place to start), not as a set a of roles and processes, but rather as a small set of patterns. These patterns are easy to recognize in people's own successful projects. What patterns do we find?
- Deliver something that works regularly
- Inspect and Adapt regularly
- A small interdisciplinary team solves the problem
- Once voice speaks for the customer / user / stakeholders
- High performance is achieved through continuous improvement
So now agreeing to do Scrum is quite easy, and we can start without any significant resistance. Why?People recognize Scrum as a place they want to be, because it is a place they have already visited and liked: A great project where work is fun.
We’re excited to announce the start of a beautiful new friendship with Zendesk! Axosoft Scrum and Axosoft Bug Tracker integrate easily with Zendesk to seamlessly connect your support and development workflows.
We’re hoping your first reaction is to go into a zen-like buddha position (see image above for reference) and soak in the awesomeness! But your second thought might be, why would Axosoft integrate with Zendesk? After all, Zendesk is a customer service and support ticketing software and so is Axosoft Help Desk. Well, here at Axosoft, we embrace diversity, even when it comes to integrating with competing help desk solutions. We realize that there are different solutions for different needs. Thus our new friendship with Zendesk opens the door for our customers who are using Zendesk as their Help Desk solution.
By integrating these two great products, you can quickly escalate Zendesk support tickets to user stories or bugs in your Axosoft backlog, and eliminate all the time your support and development teams spend duplicating items and communicating status reports. Automated workflow step actions take your productivity to the next level by eliminating the need to update the workflow status of a linked Zendesk ticket. You can even include a public or private message when the item’s workflow status is updated. The two-way communication between Axosoft and Zendesk allows your support team, developers and project managers to clearly see how an item is progressing through development.
Bonus! You can keep overhead down by not having to purchase additional licenses for your support team to access Axosoft and your devs to access Zendesk because comments and status updates flow seamlessly between the two. It’s easy then for support to respond to customers about the status and resolution of items without ever leaving Zendesk, and developers get all the details they need to resolve issues in Axosoft.
All-in-all by integrating your Zendesk and Axosoft accounts your whole team benefits:
- Reduce time spent managing user stories and bugs.
- Gain visibility into the status of tickets from inception to close.
- Save money and keep communication flowing from customers, to support, to development and management.
We’re excited to help Zendesk and Axosoft customers be even more successful! So if you don’t have an Axosoft account yet, get started here!
Wondering what’s new in Axosoft version 14.5? Well, here it is:
- Print functionality
- Sharable Dashboards
- Zendesk Integration
- More UX improvements
There are two things that should improve your reporting efforts: printing and sharing dashboards. We have replaced the PDF shortcut with a print button that will print anything you have on the screen.
That means you may include any filter, any grouping, or any view (including Card View) for your hard copy needs. The only limit is the size of your printer’s paper, so don’t go chopping trees down here.
Non-users of Axosoft may now access dashboards. Huzzah!
After you enable your API, you’re free to copy and paste the link to your dashboard and share it accordingly. You can even have it password protected for increased security. If this is making you go “yay!” then make sure you start using this ASAP to help out your execs/managers/stakeholders/customers. Here’s what to do step by step:
- Enable API
- Go to Dashboard and edit Dashboard settings
- Generate and copy the URL
We’re excited to announce a new integration with Zendesk. See our full post here or get the gist of the integration below:
- Create or link Axosoft items from Zendesk tickets
- Notify Zendesk tickets of changes from Axosoft
- Save money and keep communication flowing from customers, to support, to development and management
Information is power, and we’re giving new info to admins. Admins now get notifications when an email has failed to fire. This is located in the upper right corner by your user/admin name in the shape of a bell.
The bell glows red when an email fails, which should allow you to immediately check the email address or potentially your email account settings. If you’re ever in doubt, please contact the awesome folks in support.
Right clicking on a column now allows you to multi-select what items you’d like to sort and we’ve updated the functionality for touch screen users.
That’s all for now folks. Be on the lookout for our next release!
We are extremely delighted to announce that Scrum Sense will merge with agile42, a leading international agile consulting organisation. agile42 is headquartered in Berlin and already operates throughout Europe and North America.
The change is effective immediately. During 2015 the agile42 brand will be introduced to South Africa and over time the well-known Scrum Sense brand will be wound down.
Quoting Peter Hundermark, Agile coach and founder of Scrum Sense: “This is the most exciting time for us since founding Scrum Sense in 2007. In seeking a partner I was adamant to find an organisation that shared our philosophy of helping our clients to help themselves. Being part of the awesome agile42 family will bring key benefits to our local clients.”
Andrea Tomasini, co-founder and strategic coach at agile42, added: “Peter and I have known each other since 2008 and have collaborated before in our community work for the Scrum Alliance. With this addition we will have 8 Certified Scrum Trainers, 7 Certified Scrum Coaches and 2 Kanban Coaching Professionals. This is the largest collection of top-level certified professionals in a single organisation. Moreover, we have developed a powerful set of consulting products including the Team Coaching Framework™ and the Enterprise Transition Framework™that help our clients achieve better outcomes faster than before.”
Don’t forget about the Scrum Coaching Retreat taking place in Franschhoek on the 09-11 Feb 2015. If you are an experienced or aspiring Agile coach, the retreat will offer an opportunity to collaborate with like minded individuals, think deeply and come away with a new perspective. For more information and to book online please follow this link. Be sure to book your place soon as space is limited!
We have had a very busy & eventful year, and are looking forward to the exciting changes 2015 will bring. We would like to thank you for your continued support and wish you and your families a wonderful festive season and great start to the New Year!
Happy Holidays!Upcoming Courses Certified Scrum Master (CPT)
26-27 Jan 2015
Steenberg Hotel, Cape Town
Certified Scrum Master (JHB)
03-04 Feb 2015
FNB Conference & Learning Centre, Sandton
Steenberg Hotel, Cape Town
Certified Scrum Master (JHB)
10-11 Mar 2015
FNB Conference & Learning Centre, Sandton
Course Schedule and Book Online
The post News update 2014/12 – Scrum Sense merges with agile42 appeared first on ScrumSense.
Scrum Sense, the foremost agile consultancy in South Africa, will merge with agile42, a leading international agile consulting organisation. agile42 is headquartered in Berlin and already operates throughout Europe and North America.
The change is effective immediately. During 2015 the agile42 brand will be introduced to South Africa and over time the well-known Scrum Sense brand will be wound down.
Marion Eickmann, co-founder and CEO at agile42, commented: “We are excited to welcome well-known agile pioneer Peter Hundermark and his team to join our community. We have been most careful to ensure a good cultural fit between our two organisations. Now is the right time to join forces and establish agile42 as a truly global brand.”
Andrea Tomasini, co-founder and strategic coach at agile42, added: “Peter and I have known each other since 2008 and have collaborated before in our community work for the Scrum Alliance. With this addition we will have 8 Certified Scrum Trainers, 7 Certified Scrum Coaches and 2 Kanban Coaching Professionals. This is the largest collection of top-level certified professionals in a single organisation. Moreover, we have developed a powerful set of consulting products including the Team Coaching Framework™ and the Enterprise Transition Framework™ that help our clients achieve better outcomes faster than before.”
Peter Hundermark, said: “This is the most exciting time for us since founding Scrum Sense in 2007. In seeking a partner I was adamant to find an organisation that shared our philosophy of helping our clients to help themselves. Being part of the awesome agile42 family will bring key benefits to our local clients:
- The experience of agile42 with successful huge-scale agile transformations such as Ericsson and Siemens means we are equipped to better help large corporations.
- Agile at scale requires many additional skills and consulting products. The Enterprise Transition Framework™ from agile42 provides a way for organisations to map their paths without sacrificing the emergent nature that is foundational to agility.
- Our coaches will invest regular time cross-learning with some of the best agile coaches on the planet. This is a forge for growing our skills in the fast-paced market.
- The Team Coaching Framework™ from agile42 is another way we will foster the growth of internal coaches at our clients, enabling them to become self-sufficient faster. This is arguably the single most important success factor in sustaining an agile transition.
We are very excited to be part of this global family of talented and passionate coaches and look forward to collaborating with them and growing the agile42 brand in South Africa.
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.”
Over the past few years I’ve had the amazing opportunity to work with over 65 different teams in various levels of small, medium, and large businesses. In each case I was either leading the teams or advising the teams on how to become more adaptive. When I joined LeadingAgile, I was thrilled to have access to the systems and tools that Mike and Dennis had employed and discovered while working with the hundreds (if not thousands) of teams that they had coached over the years.
One of the first tools that I encountered was a set of adoption attributes that we could share with a team to would help the team learn about how teams operates when they are valuing: (1) individuals and interactions over processes and tools, (2) working software over comprehensive documentation, (3) collaboration over contract negotiation, and (4) responding to change over following a plan… or the agile manifesto.
From the adoption attributes I was able to work with a team to both show them the areas where they were seeing good adoption as well as the areas where they need to grow. This was incredibly helpful for the team and me as it provided a spot light into areas where I could target coaching while at the same time giving the team the opportunity to grant me permission to coach in that area.
As time went on, I had more and more opportunities to participate in organizational assessments that were aimed at understanding the organization’s business drivers, identifying their change management concerns, and identifying a pilot slice of the to-be value delivery structure where the enterprise transformation should start. Throughout this process I learned more and more on the adoption attributes and began thinking holistically around how to establish a repeatable system of transformation that was oriented around multiple phases of adoption.
Phase 1: Become predictable
Phase 2: Make risk and dependencies visible
Phase 3: Organize around capabilities to reduce or eliminate external dependencies
Phase 4: Streamline the delivery system
Phase 5: Fast ROI with quality and predictability (end-state business drivers)
This proved really helpful when framing up a roadmap for a transformation and thinking about it as an iterative and incremental process. I was able to work with both teams and business leaders to clarify a pathway towards the end-state that didn’t require me to solve all of the adoption problems at the same time. My initial hypothesis was that each of the phases would have different metrics to inform me that the key goal of the phase had been accomplished.
What I found, though, was that changing the metrics from phase to phase inspired confusion about how to know if the organization’s transformation was succeeding in delivering on the initial business drivers. In addition, I found that hitting phase 5 based on the adoption characteristics would indicate that a slice of the organization has adopted practices that could help deliver the business drivers in spirit; but, isn’t actually using business metrics to help them clarify along the way to ensure that they are able to deliver fast roi with quality and predictability.
My question then became, how can I best use the business drivers’ key performance indicators as a focusing point for throughout the transformation. One of the tools I came across for connecting the various perspectives of an organization’s health to the organizations KPI’s was the balanced scorecard.
So… here is my question/new hypothesis: is it true that for a transformation to really deliver the end-state goals, it needs to be measured through the organization’s balanced scorecard or other business metric dashboard? I think this is true and I also would advise that a transformation not necessarily be deemed a success until the scorecard demonstrates that the business is responding to change, accomplishing fast ROI with the desired quality and predictability within their markets.
The post Are We Succeeding With an Enterprise Transformation? appeared first on LeadingAgile.
In Berichten über die Generation Y (zum Beispiel Warum die Generation Y ständig unzufrieden ist) gibt es immer wieder dieses hübsche Bild vom Einhorn. Verkürzt gesagt glauben wir Y-ler, dass wir unglaublich schöne und gute Menschen seien, die alles erreichen können. Auf der anderen Seite steht die arme Geschäftswelt, die nicht weiß, was sie tun soll, da es wegen des demographischen Wandels zu einer Verknappung von Personal kommt. Wie soll man nun diese Generation Y mit ihrem übersteigerten Anspruch am besten ködern, um zukünftig an die knappen Personalressourcen ranzukommen?
Immer wenn ich sowas lese und höre, fühle ich mich traurig. Ich frage mich, ob sich wirklich jemand die Mühe gemacht hat, sich mit dieser Generation in aller Tiefe auseinanderzusetzen. Dazu ein paar Gedanken aus meinen Beobachtungen, für die ich keinen Anspruch auf Vollständigkeit erhebe:
- Ja, die Generation Y ist mit dem Gedanken aufgewachsen, sie könne alles erreichen, und es wurden ihr mehr Freiheit und Ressourcen zur Verfügung gestellt als der Generation Me.
- Diese Ressourcen und die Freiheit haben dazu geführt, dass sich diese Generation intensiv damit auseinandergesetzt hat, was Sie tun möchte - nicht damit, was Sie tun muss. Diese Art der Freiheit führt auch zu einem gewissen Problem: Wenn man alles tun kann, stellt sich die Frage, was das Allerbeste ist, und so wird eine Entscheidung immer zum Massenmord an all den übrigen Möglichkeiten. Die Generation Y wird sich immer fragen, ob sie das Beste aus sich gemacht hat, oder ob sie sich nicht für etwas anderes entscheiden hätte sollen.
- Zur Entscheidungsfreiheit und zur Ressourcenverfügbarkeit kommt zusätzlich die Entwicklung des Internets, die wir miterleben durften. Das Internet hatte vor allem drei Effekte:
- Gleich nachdem wir eine Tätigkeit aufgenommen hatten, wussten wir, dass es irgendwo auf der Welt jemanden gab, der es schon mit 10 Jahren besser, schöner und perfekter gemacht hat – egal was.
- Die Vernetzung hat dazu geführt, dass sich eine Art Untergangsstimmung breit gemacht hat. Kriege, Umweltverschmutzung, Ressourcenknappheit usw. sind unsere Freunde seit Kindesbeinen und begleiten uns auf all unseren Wegen.
- Die Demokratisierung von Wissen über das Internet hat uns auch gezeigt, dass wir als Menschen Macht und Verantwortung haben. Wenn wir es nicht tun, wird sich kein anderer darum kümmern, auf diesem Planeten etwas besser zu machen.
- Die Globalisierung hat einen irrsinnigen Konkurrenzkampf entfacht. Es gibt zwar ein paar Studienrichtungen, dank derer sich die Absolventen die Firmen aussuchen können, aber für alle anderen spricht die Nachfrage am Markt eine ganz andere Sprache. Verhandlungssicherheit in zwei Sprachen ist eine Grundvoraussetzung, Studienabschlüsse mit 1.x sowieso, und dann bitteschön noch fünf Jahre Berufserfahrung im jeweiligen Bereich. Ach ja, und natürlich nicht älter als das Golden Age 30. Sowieso, eh klar …
Erschwerend kommt hinzu, dass die Generation Y mit ihrer exzellenten Ausbildung, analytischen Kompetenz und Praxiserfahrung seit den ersten Studienjahren fähig ist, hinter die Kulissen propagierter Aussagen zu sehen. Auf gut Deutsch: Wir sind kritisch, lassen uns kein X für ein U vormachen und bilden uns gerne unsere eigene Meinung. Denn dass man Medien nicht trauen kann, wissen wir schon längst.
In diesem Sinne sind mir auf dem höher gebildeten Sektor drei Typen der Generation Y aufgefallen:
Lethargie ist da, man akzeptiert was ist, arbeitet so viel wie nötig, und sucht sich seinen Ausgleich in der Freizeit. Die Dauerberieselung durch die Medien wird akzeptiert, um den Gedanken, was sich denn hinter dieser Welt verstecken möge, zu überdecken. Man kann seine Firma im besten Falle leiden, aber da man sich bewusst ist, dass einem selten die Wahrheit gesagt wird, schaut man lieber nicht hinter die Kulissen. Stattdessen legt man sich einen Hund und eine Freundin/einen Freund zu und macht das Beste aus seinem Privatleben. Die Arbeit wird als lästiger Bestandteil akzeptiert, die innere Kündigung wird zur Dauereinstellung.Typ B – “Beat The System”
Einige der bestausgebildeten und bestvernetzten Personen sind sich darüber im Klaren wie es läuft, und versuchen es mit der “AUA-Methode” des Vertriebs: Im Sinne des “Anhauen – Umhauen – Abhauen” versuchen sie innerhalb kürzester Zeit die Karriereleiter zu erklimmen und mit viel Geld auf der hohen Kante aus dem System so bald wie möglich auszusteigen. Ob das gelingen wird, oder ob die Räder des Systems zu einem anderen Ergebnis führen, sei dahingestellt.Typ C – “Better Do Something Than Nothing”
Dieser Typ hat sich letztendlich seiner Verantwortung gestellt. Ihm ist klar, dass sich die Welt nur mit seiner Hilfe verändern wird. Er hat sich lange gefragt, was ihm wirklich am Herzen liegt und wo seine Kompetenzen liegen. An diesen arbeitet er kontinuierlich und ist bereit, dafür Opfer aus seinen anderen Lebensbereichen zu bringen, da er mit seinen Fähigkeiten etwas (zum Besseren) bewegen will. Diese Leute überlegen gut, wo sie sich einbringen, gehen ihren Leidenschaften nach und sind kritisch und sehr aufmerksam, was den Zweck und den Wahrheitsgehalt einer Firma betrifft.
In diesem Sinne liegt es an Ihrer Firma zu entscheiden, welche Menschen sie anziehen möchte und wer sich für sie einsetzen soll. Typ A braucht nicht viel und wird Ihnen auch nicht viel zurückgeben. Typ B wird seinen Bezugspunkt über das Gehalt definieren, seien Sie sich dabei aber im Klaren, dass er Sie genau so schnell wieder verkaufen wird, wie Sie ihn eingekauft haben. Typ C ist vermutlich der heilige Gral, den Sie suchen.
Wenn Sie den wollen, wird Ihr Unternehmen authentisch sein müssen. Eines, das aufrecht zu seinen Aussagen steht. Ein Unternehmen, in dem Leute arbeiten, die inspirierend sind und nicht davor zurückschrecken, sich Fehler einzugestehen, die bereit sind, ihren ehrlichen, nach bestem Wissen und Gewissen eingeschätzten Beitrag zu einer besseren Welt beizusteuern. Abgesehen von einer gewissen emotionalen Intelligenz (aka Bauchgefühl) finden wir Y-ler auf Firmenbewertungsportalen mehr als genug Infos, um zu wissen, wer es ernst meint und wer nicht. Stecken Sie also in Ihrem eigenen Sinne die Energie und die Ressourcen Ihres Unternehmens nicht in das Verdecken von Schwachstellen, sondern arbeiten Sie ehrlich an der Authentizität.
Wenn Sie noch weiter gehen wollen, gehen Sie ein Stück in Richtung Demokratisierung. Ricardo Semler hat es mit Semco vorgezeigt: Vom Umsatzwachstum abgesehen kann er aus einem unerschöpflichen Pool der besten Studienabgänger schöpfen.
Es liegt an uns, an der Generation Y, zu entscheiden, wie es mit dieser Welt weitergehen soll. Es liegt aber an den Verantwortlichen in den Unternehmen, zu entscheiden, ob sie uns dabei helfen wollen, die Welt zu einem besseren Ort zu machen. Falls ja, können Sie sich unserer Loyalität sicher sein. Falls nicht, werden wir unsere eigenen Firmen gründen, um es zu tun. Denn irgendwer muss es tun.
I sometimes see clashes between Kanban proponents and their Scrum counterparts. Despite the disagreements, both of these approaches tend toward the same goals and use many similar techniques. Karl Scotland and I did some root cause analysis of practices a few years back and came to the conclusion that there were a lot of similarities between Kanban and Scrum [as the poster-child of iterative agile] when viewed through that lens. I also noticed that while Scrum explicitly focuses on iterations as a control mechanism, Scrum teams tend get into trouble when they ignore Work In Progress (WIP). Conversely, while Kanban explicitly focuses on WIP, Kanban teams tend to get into trouble when they ignore Cadence.
A twitter conversation I was in revolved around Cycle Time and Velocity. Since this is a topic that’s come up before, I thought it would be valuable to describe it more fully. Again, I find there to be more similarities than differences between Kanban (which uses Cycle Time) and Scrum (which uses Velocity) in terms of predicting when a given amount of work will be done, or how much work will be done by a given time.
Cycle Time is the amount of time it takes for a single unit of work to progress from one identified point in the value stream to another. Since the term originated in manufacturing, it assumes that the units of work are essentially identical, and the variability of cycle time is low. The concept also assumes that one can relatively easily produce multiple units in parallel, increasing production capacity and reducing the average cycle time by a factor equal to the number of parallel streams (assuming they are all equally efficient). These assumptions can work with knowledge work like software development, but we do need to be careful that we’re not violating them.
Velocity is the amount of work that can be accomplished in a given unit of time. Velocity is often expressed in “story points” which take the perceived difficulty of a story into account. This generally adds noise to the data, so you’ll likely find it easier to work with a count of stories, instead. Even better, we can split our User Stories until they are of roughly equal size, and call them all “one point” stories. Even if you’re using story estimates for your tracking, then you can easily record the story count, too. If we use multiple teams to produce multiple units in parallel, then the velocities (in story count) may be added to give the overall capacity. (I recommend against adding story points from multiple teams.)
Given that Cycle Time is Time per Work, and Velocity is Work per Time, by adjusting for units we see that these are reciprocals of each other. They are related in the same way that wavelength and frequency are in physics.
If our average cycle time is 2.5 days per story, then the velocity for a two week cadence (10 working days) is 4. Similarly, if a team produces 15 stories in 10 working days, then the cycle time is 2/3 of a day.
For most decision making, people use average cycle time rather than the cycle time of individual units of work. Velocity will always average over the length of a sprint, at minimum. You can, of course, measure cycle times of individual stories. This will enable calculating or eyeballing the variability.
I was asked why I would want to make such a conversion. I can think of four reasons off the top of my head.
1. To look at a situation from a different perspective to gain insights.
2. To understand someone speaking from a different context.
3. To work with organizations where they are, rather than expecting them to conform to my preferences.
4. To reason using the data that’s available, rather than waiting to collect different data.
I don’t mind which framework people use, but I care that that they get the benefits of using it. Sometimes this requires borrowing concepts from another framework to understand what you’re seeing or make a needed adjustment.