I will give two workshops in Kladno (near Prague) on Getting More out of Agile and Lean. In these workshops you’ll learn practices to develop the right products for your business and customers, reduce your delivery time, increase the quality of your software, and create happy high performing teams.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
These workshops are done in collaboration with Aguarra, the competence center for agile techniques and technology innovations in Czech Republic, Slovakia and Hungary. Aguarra serves as a platform for experts, who work on research and implementation of agile techniques.
The workshop on Getting More out of Agile and Lean can be combined with the workshop on Valuable Agile Retrospectives that I’m giving on on November 1 or December 1. These two days of workshops on Retrospectives and Agile and Lean practices help you to boost the performance of your teams, enabling them to deliver more value to their customers and stakeholders.
Regular price is 480 EUR / 576 EUR. Price when ordering until 01. 09. 2016 : 440 EUR / 528 EUR.
When you receive a letter that has an official The White House logo on it, you basically have two options: jump for joy or run for the hills! Fortunately, I was a jumper. It read:
Dear Tania, Congratulations! You are one of the nominees chosen to attend The United State of Women Summit on June 14th here in Washington, D.C. We appreciate the work you do to further gender equality and hope that you’ll be able to attend.
So, yes, my job at Axosoft (and in life) is disrupting the status quo, especially when it comes to gender representation in STEAM fields! As co-creator of the #ItWasNeverADress campaign, I speak to thousands (getting close to millions) of people about shifting perceptions and assumptions about women in the world.
Last week, I joined 5,000 women in Washington, D.C. for the first-ever White House Summit on the United State of Women.
And, I’m sad to report, like most government agencies, the line to get in was really long! Fortunately, everyone in line was a “changemaker.” It was filled with leaders, organizers and activists from around the globe who are rallying for economic empowerment, changing health and wellness policies, creating bridges into education, starting businesses, and changing the culture to end violence against women.Standing in line was a good time. It was like summer camp for the most inspiring people you will ever meet!
After more than 13 hours of the most electrifying, heartbreaking and dynamic speeches, stories, panels, and songs; after the President of the United States of America said, “This is what a feminist looks like”; after Jaha Dukureh, a survivor of female genital mutilation said, “I stand here to represent a forgotten population: girls who are a footnote in research papers and never make it past lunchtime conversations”; in the wave that is Oprah Winfrey taking the stage and in her iconic “You get a car!” voice screaming, “We are here for the UNITED STATE OF WOMEN!!”; in a room full of women of color; full of survivors; full of doers, dreamers and those who dare, we reached a peak.Perhaps that’s why they called it a summit.
When I left this historic event, deeply moved and profoundly inspired, I kept thinking, what’s next? How do we take this momentum and turn it into action? What can we do every day that will make a difference? How do we continue this movement? How do we, in the words of First Lady, Michelle Obama, “BE better”?“BE better.”
Turns out, the trailblazers presenting at The United State of Women Summit created a map to help us take action! I identified 6 key roadside attractions I’d like to point out.6 stops on the road map to being better 1. Disrupt the status quo. “Disruption is the only thing that causes change.”Brittany Packnett, Teach for America
Go ahead, pick a system that is clogged up: the economy, education, health care, safety… and interrupt it! Let’s take women in technology for instance. As an Evangelist for a tech company, Axosoft, my job is to stand up in front of 2,000 or more technologists and tell ‘em why it’s important to embrace diversity.
Oftentimes, I’m the only playwright in the room, the only woman in the room, the only LGBT person in the room. As I see it, the more I show up, the more I’m myself, the more I point out subtle (and not-so-subtle) injustices that exist when we think everyone is the same, the more meaningful conversations we can have.“Strategically disrupt the status quo by men and women working in tandem. There must be a willingness to be present, a genuine desire to listen, and the ongoing commitment to transform men.”Matt McGory, Actor on How To Get Away With Murder 2. Make a pledge.
A pledge is a promise, an undertaking, an action. And guess what? We’ve been pledging our allegiance to the flag of this awesome country since we entered the school system, so we know how to do it!
Make your pledge to ensure all human beings are seen, heard, safe, supported and given the resources that every human being deserves.“I will use my voice in service of those who don’t have a voice right now.” “So, President Obama and I started It’s On Us—to wake-up our colleges and universities–and the country–to the epidemic of sexual violence on their campuses.”Joe Biden, Vice Presiden of the United States 3. If you don’t see something, say something.
Oftentimes we are at work, on a panel, in the audience or simply flipping through a business journal and become painfully aware that women and people of color are missing from these spaces; so let’s say something!
Adecco’s research shows that 85% of large global enterprises believe that diversity is critical to fostering innovation in the workplace.
If we say something, we’re helping our companies become more innovative and we’re honoring the company we keep!“If your companies, organizations, and boards don’t have women, you’re not doing women’s work.”Cherno Biko, CoFounder, #BlackTransLivesMatter 4. Humor is a serious tool.
As we all know, chitty-chatting about politics can raise one’s heart rate and, sometimes, alienate the very people we need to connect with in order to create change. Next time you find yourself, ahem, raising your voice at an opposing P.O.V., try finding a connection that you and your adversaries share. Crack a joke, and you just might just make a new ally!
“We use humor. It’s a great way to get people in politics talking about important issues.” Erin Loos Cutraro, Co-Founder & CEO, She Should Run5. Stop name-calling and start dreaming + doing!
When Mikaila Ulmer took the stage, small in stature, but HUGE in confidence and focus, she reminded all of us big shot adults, that the true source for innovation is dreaming; no matter if you are 11 or 100 years old!“Entrepreneurs hold the American dream & the biggest dreamers are kids.”Mikaila Ulmer, 11-Year-Old Businesswoman and Entrepreneur
When First Lady Michelle Obama was in conversation with Oprah (yes, it was amazing), she spoke candidly about the name calling she’s experienced on social media, the bullying aimed at women and at people of color, and the intensity added when your husband is running for president.
Early on in her husband’s bid for office, she stopped engaging in all the noise and realized that, ‘It’s what I do, not what you call me.’
Do you have a dream of leading your team in creating new software, wanna write a book, travel around the world, start your own business?
Ask yourself, ‘What is one thing I can do today, to move forward on my dream map?’
It’s time to do one thing. Reach out to a software developer, start writing, buy a ticket, email an entrepreneur and ask for advice. All it takes is one gesture to swiftly move your dreaming to doing!What’s your dream? You can make it happen. 6. Make caring your business. “When you’re building a culture, every person matters.” Melanie Whelan, CEO, SoulCycle
Whether you’re at the helm of a large company, like SoulCycle, or compelled to start an organization, like Kechie’s Project, caring is a powerful catalyst! What do you care deeply about? It’s time to pair your skills with your caring and innovate the workplace as well as the worldplace!“In 2011, my 68-year-old mother was kidnapped for ransom in Enugu State of Nigeria and was held for two months… This situation has increased my drive to give a voice to other women in Nigeria and other countries in Africa, who cannot speak out for themselves against the onslaught of injustices.”Nkechi Ogbodo, Founder and President, Kechie's Project
If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You have already made the big decisions: which feature/parts of features do you want when? You made those decisions based on value to someone.
I see many POs try to use estimation as their only input into ranking stories. How long will something take to complete? If you have a team who can estimate well, that might be helpful. It’s also helpful to see some quick wins if you can. See my most recent series of posts on Estimation for more discussion on ranking by estimation.
Estimation talks about cost. What about value? In agile, we want to work (and deliver) the most valuable work first.
Once you start to think about value, you might even think about value to all your different somebodies. (Jerry Weinberg said, “Quality is value to someone.”) Now, you can start considering defects, technical debt, and features.
The PO must rank all three possibilities for a team: features, defects, and technical debt. If you are a PO who has feature-itis, you don’t serve the team, the customer, or the product. Difficult as it is, you have to think about all three to be an effective PO.
The features move the product forward on its roadmap. The defects prevent customers from being happy and prevent movement forward on the roadmap. Technical debt prevents easy releasing and might affect the ease of the team to deliver. Your customers might not see technical debt. They will feel the effects of technical debt in the form of longer release times.
Long ago, I suggested that a specific client consider three backlogs to store the work and then use pair-wise comparison with each item at the top of each queue. (They stored their product backlog, defects, and technical debt in an electronic tool. It was difficult to see all of the possible work.) That way, they could see the work they needed to do (and not forget), and they could look at the value of doing each chunk of work. I’m not suggesting keeping three backlogs is a good idea in all cases. They needed to see—to make visible—all the possible work. Then, they could assess the value of each chunk of work.
You have many ways to see value. You might look at what causes delays in your organization:
- Technical debt in the form of test automation debt. (Insufficient test automation makes frictionless releasing impossible. Insufficient unit test automation makes experiments and spikes impossible or quite long.)
- Experts who are here, there, and everywhere, providing expertise to all teams. You often have to wait for those experts to arrive to your team.
- Who is waiting for this? Do you have a Very Important Customer waiting for a fix or a feature?
You might see value in features for immediate revenue. I have worked in organizations where, if we released some specific feature, we could gain revenue right away. You might look at waste (one way to consider defects and technical debt).
Especially in programs, I see the need for the PO to say, “I need these three stories from this feature set and two stories from that other feature set.” The more the PO can decompose feature sets into small stories, the more flexibility they have for ranking each story on its own.
Here are questions to ask:
- What is most valuable for our customers, for us to do now?
- What is most valuable for our team, for us to do now?
- What is most valuable for the organization, for us to do now?
- What is most valuable for my learning, as a PO, to decide what to do next?
You might need to rearrange those questions for your context. The more your PO works by value, the more progress the team will make.
The next post will be about when the PO realizes he/she needs to change stories.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
One of the biggest buzzwords in the industry lately is DevOps. We all know by now what DevOps is intended to offer, and most organizations are looking for at least some subset of the promise of a continuous delivery flow and the power of “pulling ops into the room”. But can we really do that if our own job of becoming “more agile” is still incomplete?
Let’s explore for a moment what we even mean by agile. I recall back in the early days that agile discussions were about how to turn around features quickly by breaking them down into smaller “bite sized” chunks, delivering those, and then determining where to go next based on that feedback. We invented cool things like user stories, and utilized mechanisms like short iterations and daily standups to move closer to this fast-paced, turn-on-a-dime philosophy toward software development. We discovered, without a doubt, that this was a better way. One major portion of these methods was a set of technical practices that would enable the teams to write software in a way that would support such a nimble environment.
So, where are we now? We have discovered that doing things in these small chunks is hard. It is counter intuitive too. We want to look at things in big picture terms. The question I used to hear the most was “how can I manage a portfolio this way?” Now that question has been turned into “how can we scale this?” My answer to each question is the same: Don’t. The reason we moved to the smaller chunks and stories is because the “big picture” approach doesn’t work. So finding ways to shoehorn agile methods into “scaled” or “Big Up Front Agile” is a waste of time and energy. Rather, let’s learn how to do the real agile methods better, and reap the well-known benefits.
What does this have to do with DevOps? Hang on, we’re getting there. One of the things that got set aside along the way was the focus on practices that enable agility. Test Driven Development (TDD) was at best assumed it would magically happen, and more often set aside as something “we’ll get to once we get all of our release trains and architectural runways laid out”. In other words, never. A possible metaphor is saying “I will start exercising once I’m in better shape.” You have to do the technical practices first, or the rest is just a waste of time. And this is where DevOps comes into play.
DevOps is most closely associated with the idea of Continuous Delivery. The idea that we can at any time build and deploy the results of our development efforts allows us a huge amount of flexibility with deciding what software gets delivered and when. The tools that help us, whether it be for visualizing and orchestrating the moving parts of build, test, and delivery, or the tools that automate these parts, have reached a level of maturity that allows us to move forward. The question remains, does your team have that same level of maturity?
If the extent of your team’s agile mechanisms is identifying “portfolio items” that will be broken into stories that will then be scheduled into sprints, do NOT try to go straight to DevOps. Learn how to truly embrace TDD, both at the Unit Test level and the Acceptance Test level. Once you feel comfortable with that, you can move to Continuous Integration and then Continuous Delivery and DevOps.
If you are doing “some TDD” and daily builds, you are getting there, but ramp up the tests first. You might be inclined to at least get some of the cool DevOps tools into place, but I highly recommend getting your TDD house in order first. Time and energy are finite, so let’s spend them appropriately.
If you still have a “change control board” of some type that controls when a merge happens, you aren’t ready for DevOps. Ensuring that your tests are in place and automated will help build the trust necessary to avoid constructs that are explicitly designed to slow the development process down. Building habits of checking in code and building several times a day will allow us to catch what errors might make it through quickly, and with a much smaller delta between check-ins to identify where the errors might have come from.
So, am I being somewhat absolutist here? Absolutely. Rather than taking our agile practices halfway there and then saying “hey I know, let’s do DevOps now”, work on making agile everything it possibly could be. Once you feel comfortable with your automated tool stack and delivering every iteration, then move to Continuous Delivery and DevOps.
That was the question that was posed to the freshly minted staff at the Open House for Friends and Family for Publix Grocery Stores store #1520 yesterday. It was amazing to be invited to witness the internal opening of one of Publix’s newest stores in Cary, NC.
The air was thick with excitement. Executives traveled in from the regional offices in Charlotte and from the corporate headquarters in Tampa, FL. We met the store leadership. We met everyone.
When it came time for the ribbon cutting, the newly minted store manager took the stage and posed this question, “Who owns this house?” It was met with a resounding, “We own this house!”
Three times the call came.
Three times it was met with with a loud cheer, “We own this house!”
Kevin Murphy, SVP of Retail Operations, summed up Publix’s success as being rooted in two key principles: ownership and pride in your work at every level of the organization. Kevin should know. He started as a front-service clerk at a Publix in 1984. He worked in various positions before being promoted to store manager in 1995. He was promoted to Jacksonville Division district manager in 2003, Atlanta Division regional director in 2009, Miami Division VP in 2014, and his current position was created in 2016.
Ownership and pride in work at all levels. Sounds like the same formula for success in Agile Product Development.
This is also the core of LeadingAgile’s approach to transformation from Basecamp One through Basecamp Five. Without local ownership of decision making at the point of the work being done, we send the message consciously on subconsciously that we don’t trust that the work being performed is high-quality and valuable.
If it isn’t valuable then why are you doing it? Non-valuable work is called waste.
If the work isn’t high-quality, then why? Do you have the correct expectations of how long the work should take? Are you measuring quality correctly? (hint: it’s not just about defect injection rate.) Do you reward the wrong things like heroic efforts?
This is the heart of Agile practices. It expects ownership and pride in work. It expects trusting the people doing the work to know what they are doing. If they don’t, it expects you to let them self-organize to the extent that people who know how to do the work well, can volunteer to do it with the expectation that they also mentor those that don’t.
What about your company? Does it espouse a culture of ownership and pride in work? How would you know? Our assessments cut right to the heart of the matter and help organizations determine if leadership is creating and empowering a culture of ownership and pride in work.
Wouldn’t you like to know?
Congratulations to the people of Publix Store #1520. I can’t wait to experience more ownership and pride in work. The world needs more of it.
When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take. Oh, and the POs want to change things as soon as they see them.
I don’t see this as problems.To me, this is all about learning. The team learns about a feature as they develop it. The PO learns about the feature once the PO sees it. The team and the PO can learn about the implications of this feature as they proceed. To me, this is a significant value of what agile brings to the organization. (I’ll talk about technical debt a little later.)
One of the problems I see is that the PO sees the big picture. Often, the Very Big Picture. The roadmap here is a 6-quarter roadmap. I see roadmaps this big more often in programs, but if you have frequent customer releases, you might have it for a project, also.
I like knowing where the product is headed. I like knowing when we think we might want releases. (Unless you can do continuous delivery. Most of my clients are not there. They might not ever get there, either. Different post.)
Here’s the problem with the big picture. No team can deliver according to the big picture. It’s too big. Teams need the roadmap (which I liken to a wish list) and they need a ranked backlog of small stories they can work on now.
In Agile and Lean Program Management, I have this picture of what an example roadmap might look like.
This particular roadmap works in iteration-based agile. It works in flow-based agile, too. I don’t care what a team uses to deliver value. I care that a team delivers value often. This image uses the idea that a team will release internally at least once a month. I like more often if you can manage it.
Releasing often (internally or externally) is a function of small stories and the ability to move finished work through your release system. For now, let’s imagine you have a frictionless release system. (Let me know if you want a blog post about how to create a frictionless release system. I keep thinking people know what they need to do, but maybe it’s as clear as mud to you.)
The smaller the story, the easier it is for the team to deliver. Smaller stories also make it easier for the PO to adapt. Small stories allow discovery along with delivery (yes, that’s a link to Ellen Gottesdiener’s book). And, many POs have trouble writing small stories.
That’s because the PO is thinking in terms of feature sets, not features. I gave an example for secure login in How to Use Continuous Planning. It’s not wrong to think in feature sets. Feature sets help us create the big picture roadmap. And, the feature set is insufficient for the frequent planning and delivery we want in agile.
I see these problems in creating feature sets:
- Recognizing the different stories in the feature set (making the stories small enough)
- Ranking the stories to know which one to do first, second, third, etc.
- What to do when the PO realizes the story or ranking needs to change.
I’ll address these issues in the next posts.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories. See the wikipedia page about user stories. Notice that they are a promise for a conversation.
I talked about feature sets in the first post, so let me explain that here. A feature set is several related stories. (You might think of a feature set as a theme or an epic.) Since I like stories the team can complete in one day or less, I like those stories to be small, say one day or less. I have found that the smaller the story, the more feedback the team gets earlier from the product owner. The more often the PO sees the feature set evolving, the better the PO can refine the future stories. The more often the feedback, the easier it is for everyone to change:
- The team can change how they implement, or what the feature looks like.
- The PO can change the rest of the backlog or the rank order of the features.
I realize that if you commit to an entire feature set or a good chunk for an iteration, you might not want to change what you do in this iteration. If you have an evolving feature set, where the PO needs to see some part before the rest, I recommend you use flow-based agile (kanban). A kanban with WIP limits will allow you to change more often. (Let me know if that part was unclear.)
Now, not everyone shares my love of one-day stories. I have a client whose team regularly takes stories of size 20 or something like that. The key is that the entire team swarms on the story and they finish the story in two days, maybe three. When I asked him for more information, he explained this it in this way.
“Yes, we have feature sets. And, our PO just can’t see partial finishing. Well, he can see it, but he can’t use it. Since he can’t use it, he doesn’t want to see anything until it’s all done.”
I asked him if he ever had problems where they had to redo the entire feature. He smiled and said,
“Yes. Just last week we had this problem. Since I’m the coach, I explained to the PO that the team had effectively lost those three days when they did the “entire” feature instead of just a couple of stories. The PO looked at me and said, “Well, I didn’t lose that time. I got to learn along with the team. My learning was about flow and what I really wanted. It wasn’t a waste of time for me.”
“I learned then about the different rates of learning. The team and the PO might learn differently. Wow, that was a big thing for me. I decided to ask the PO if he wanted me to help him learn faster. He said yes, and we’ve been doing that. I’m not sure I’ll ever get him to define more feature sets or smaller stories, but that’s not my goal. My goal is to help him learn faster.”
Remember that PO is learning along with the developers and testers. This is why having conversations about stories works. As the PO explains the story, the team learns. In my experience, the PO also learns. It’s also why paper prototypes work well. Instead of someone (PO or BA or anyone) developing the flow, when the team develops the flow in paper with the PO/BA, everyone learns together.
Small stories and conversations help the entire team learn together.
Small features are about learning faster. If you, too, have the problem where the team is learning at a different rate than the PO, ask yourself these questions:
- What kind of acceptance criteria do we have for our stories?
- Do those acceptance criteria make sense for the big feature (feature set) in addition to the story?
- If we have a large story, what can we do to show progress and get feedback earlier?
- How are we specifying stories? Are we using specific users and having conversations about the story?
I’ve written about how to make small stories in these posts:
- Make Stories Small When You Have “Wicked” Problems
- Three Alternatives for Making Smaller Stories
- Feature sets in How to Use Continuous Planning
- Reasons for Continuous Planning
The smaller the story, the more likely everyone will learn from the team finishing it.
I’ll address ranking in the next post.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
Description of charts:
Burndown chart - a daily count of the number of task units (aspirin is this teams selected units for task estimation) not done. This includes the task yet to be started, and task in process.
Tasks in Process - a daily count of the number of tasks in process.
Tasks Done - a daily count of the number of tasks that are done.
Stories Done - a daily count of the number of Stories that are done.
Velocity - the empirical measure of Stories that are considered done by the team and accepted as done by the Product Owner during the Sprint Review.
The Back Story on this team:
This team had been attempting to do some form of ad-hoc Scrum / Kanban with little guidance and understanding of the process. The Kanban aspect came from the company's tooling (RTC) template - not from any real practices the team was implementing. After some weeks of observations and workshops with the team - they decided to "hit the reset button" on doing Scrum. Sprint One in the info-graphic is the first sprint right after a week long workshop on learning Scrum practices and principles. Key to this team's adoption of Scrum is their adoption of a physical task board (see also Elements of an Effective Scrum Task Board).
Observations on Sprints:
Sprint One - Started with many stories from past sprint that were not yet done - as the team had no empirical data of velocity we guessed at how many stories we could complete in the 2 week sprint, and chose 15 stories. At this point we had 4 product silos where people we working within the silo to deliver the stories - very little cross team collaboration.
Rules siloSprint Two - Tear down the silo walls - the team decided that the original silos of working was harming a long term desire of cross-functional team members - so a removal of the silo walls (tape on the scrum task board) happened.
Sprint Three - Enforced the use of empirical data to constrain the team's selection of how many stories to bring into the sprint (team select top 5 stores and finished all of them).
Sprint Four - Team planed for 30 points of stories but finished early and pulled in additional stories and finished them within the sprint.
Objectives for the Team:
This teams objectives for hitting the reboot button on a scrum implementation was to achieve a consistent level of reliability to deliver value (stories) to the business. Also to maintain and supporting the existing 4 products line internal organizational clients, and transitioning tacit knowledge from several remote employees to the team and increasing cross-functional capabilities of the team members.
Commentary on Metric Charts:
Burndown - Sprint 1 and 2 task burndown charts show that the team started with around 100 aspirin and discovered between 50 and 100 aspirin more by doing the work - but didn't finish the 15 stories and left lots of stories started but incomplete at the end of the sprint. In sprint 3 and 4 the team had developed the ability to forecast the proper amount of work to pull into sprint planning and were able to deliver the completed stories.
Tasks in Process - this simple metric showed that the team of about 8 people were consistently task switching. There are many "reasons" (excuses) for this behavior, and it is a hard habit to correct in this era of high utilization rate driven management. Just tracking this metric had little effect on the teams behavior - however we had empirical data that other practices (avatars, re-estimating in process tasks, etc.) had a positive effect upon this metric over several sprints.
Tasks Done - this metric is redundant for a team using a traditional sticky note task board. In general this reflects the sprint burndown. It does point out for this team that tasks done stalls out when there support tasks flare up, as these support (maintenance and production, M&P) issues require task switching to the more urgent unplanned work. Reflecting upon this metric lead the team to start tracking the planned tasks separate from the urgent support tasks in our burndown chart for sprint 5.
Stories Done - an interesting trend shows up in this simple to trend metric. The team was capable of finishing 5 stories, regardless of how many they planned. In sprint 3 when the team constrained the planning to the empirical evidence (~28 points, 5 stories) they had there first successful sprint (on time, on budget, with planned scope).
Capabilities developed by the Team not shown in these Metrics:
Tasking - working toward tiny tasks. Within the first two sprints the focus was to develop the ability to task stories. Several synergic practices lead to this capability - re-estimating each time the task is touched in stand-up; recognizing that task that last for several days are way-too-large; learning to decompose tasks that are too large; realizing that doing work leads to discovery of new tasks that need to be recorded and added to the board. See Also: What belongs on the TASKS board?
Single Piece Flow - working on a task until it is done. Smaller task effect this behavior in a virtuous manner. Re-estimating each day makes the antithesis of this pattern apparent, and also offers the opportunity for team members to recognize when help is needed. The use of avatars on the story tasks reinforces the practice of lowering work in process and reducing task switching.
In Sprint 5 the team decided to move from a 2 week time box to a 3 week sprint. The charts also show the support (M&P) tasks tracking independently of the planned tasks and the new chart at the bottom (M&P task vs Planned task deltas per day) indicates the inverse relationship of the priority shifts the team has to deal with.
Develop the capabilities to deliver agile release plans and forecast feature release time frames for business coordination with other teams that depend upon the infrastructure product lines developed by this team.
At the team coaching level an objective is to measure cycle time of stories within scrum teams.
Metrics for a Scrum Team - 10 suggested metrics and examples
Measuring Process Improvements - Cycle Time by Mishkin Berteig, June 2008
7 Lean metrics to Improve Flow - LeanKit
Agile is hot! Kleine en grotere organisaties zijn bezig met het invoeren van agile, vaak met (grootschalige) veranderprogramma’s die niet altijd tot succes leiden. Met een plan wordt je niet agile, dat gebeurd door daadwerkelijk te veranderen, door het te doen. De vraag is: Hoe kun je agile worden door agile te doen.
Agile is geen doel, het is een middel wat je slim toepast om sneller en flexibeler te worden en meer waarde te leveren. Agile principes en practices van b.v. Scrum en Kanban helpen om je de agility van je organisatie te verhogen. Agile doen
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
Als ik organisaties help bij het toepassen van agile dan begin ik vaak met kleine veranderingen waar op kortere termijn winst te halen is. Van zulke veranderingen leert de organisatie dat ze kunnen veranderen. Ze zien de waarde van de verandering snel terug. Dat versterkt het effect en geeft energie voor verdere verandering. Ze worden meer agile door agile te doen.
Ook pak ik die veranderingen aan waar een groot risico zit. “Learn fast by failing fast.” Dat helpt ook om mensen wakker te schudden. Als het lukt, dan is het een mooi bewijs dat veranderen kan. Gaat het fout, dan weten we dat die aanpak niet de oplossing is. Een leermoment waarvan we beter en sterker worden. Kortom, het kan niet fout gaan. Agile zijn
Managers vragen mij wanneer ze “agile zijn”. Agile is nooit “af”. Het is geen kwestie van Scrum, Kanban of SAFe invoeren. Het is een reis van continue verbetering, waarin de resultaten van de organisatie steeds verder groeien. Onderweg borg je veranderingen om te zorgen voor blijvend resultaat.
Met agile worden organisaties beter in staat om zich aan te passen aan veranderingen in hun omgeving, en leveren ze meer waarde aan bestaande en nieuwe klanten. Dat houdt nooit op, gelukkig maar. Agile worden
Het nadeel van een veranderprogramma met een plan is dat het de suggestie wekt dat er een einddoel is waarin de organisatie agile is. Om geen verkeerde verwachtingen te wekken werkt ik bij voorkeur met een verander backlog. Daarin staat wat we de komende tijd gaan doen, en waarom we dat doen, om agile te worden. Continue verbeteren met Agile!
Met de feedback van de veranderingen, veranderen de prioriteiten in de veranderbacklog. Er komen dingen bij en vallen er dingen af. We komen nooit op een punt waarop alles gedaan is. We zorgen er op deze manier wel voor dat we met de belangrijkste veranderingen bezig zijn. Is dat genoeg? Voor veel organisaties wel! Continu Verbeteren
Verbeteren kan en moet anders. Continu maar beheerst veranderen, in kleine stapjes op weg naar meer resultaten. Mijn aanpak maakt de veranderingen inzichtelijk en geeft stakeholders een instrument om mee te sturen. De workshop continu verbeteren met Agile zorgt voor tevreden klanten, stakeholders en medewerkers!
Hopelijk heeft dit artikel je geholpen om manieren te vinden om agile worden door agile te doen. Ik ben benieuwd naar jouw ervaringen. Wat doe je om de agility te verhogen? Wat werkt, en wat niet? Deel je ervaringen middels een comment op dit artikel.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
I recently emailed everyone who subscribes to my weekly tips a list of suggestions for ways to motivate team members to arrive on time to the daily scrum. For example, many teams have a rule that if you arrive late, you put a dollar in a jar as punishment for being late. Ideally the collected money is donated to a charity at the end of a project or after it reaches a certain amount.
I included a number of other techniques I’ve seen Scrum Masters use. Many were similar to paying a dollar in that they were punishments for being late. Wow, did I get called out for that. The general argument was that a Scrum Master should use an incentive for being on time rather than a punishment for being late.
That’s a really good point. But I have to say that in the vast majority of teams I’ve seen, they use a punishment rather than an incentive. Many of the punishments involve at least the potential for embarrassing the offender--sing a song, do a pushup, tell a joke, etc.
I’ve thought about why this is. It may be because it’s more natural (for many of us?) to harass the one rule-breaker than reward everyone else. Or maybe it’s because embarrassing the late arriver by making that person sing (for example) is more fun for everyone else.Incentives Rather than Punishments
I do think, though, that it’s a great suggestion that we look for incentives rather than punishments. Besides, punishment may be too strong of a term. I was told by a couple of people that deterrent might be the better term.
In fact, Rob Dull pointed out an underlying benefit to using a deterrent, saying, “It's sooo healthy for people to be able to be silly/awkward in front of their teammates.”
Others considered the entire idea “stupid,” as one email I received succinctly put it. While others pointed out that the only real fix is to tap into an intrinsic motivation to get latecomers to arrive on time.
Isaias Fritsch took that type of approach by preparing a 30-minute presentation for the team on the importance of the daily scrum. He said that after that presentation, the team decided to come up with some changes to their daily scrum approach. The result of this has been that “the daily scrum is now way more interesting to everyone because relevant information is shared and everyone understands its importance/why we are doing it.”
Ted Morris Dawson had an interesting take on the punishment vs. incentive idea. One technique he has used was if all team members are on time for all daily scrums, then it’s the Scrum Master who does the embarrassing thing like sing, tell a joke or so on. Yikes!
So with the idea that we can help teams overcome the problem through either deterrents or incentives, I’ve split the suggestions I was emailed into lists of each.Deterrents
- Read a tongue-twister to the team (“Seventy-seven benevolent elephants” or “Scum-sucking scrum teams scrounge scrumptious scraps.”)
- Dance alone without music for five seconds. Rob Dull reported, “It's quick, amusing for everyone, and it's a healthy encouragement of vulnerability.”
- Bring coffee or a snack for the team the next day. Be careful--a few people emailed about gaining weight from this one! :)
- Have a “tardy board” as Nadine Sullivan called it that tracks late arrivals or absences. Add rules like everyone is allowed one late arrival during some period. But after reaching some number of late arrivals or absences, the person has to bring something in such as a snack for the team.
- Toss a beach ball, stuffed animal or some other item to the person who is to speak next. Throw, don’t toss, it at any late arrivers.
- Buy the team an afternoon snack or tea.
- Present a 30-minute knowledge sharing session on a topic. This was pointed out as being particularly helpful in team building.
- Facilitate the next review or retrospective.
- Facilitate the next daily scrum, meaning everyone is waiting for tomorrow’s meeting to start if today’s late arriver is late again.
- Be the team’s “slave for a day” by doing things like getting snacks, soda and coffee for anyone who needed anything from the kitchen.
- Take detailed, precise notes for the meeting.
- Solve a tricky math problem on the board.
- Buy a book for the office library. How about one one my books? :)
- Close the door. A late arriver has to open it to enter, which focuses attention on the person.
- Take on a short (perhaps 15-minute) administrative task the team needs done.
- Simply put an indicator to each person’s name on a wall to show how frequently each team member was late.
- Reward the first people to arrive with small bits of chocolate.
- Collect a dollar or two for being late, but when the money is donated to a charity, donate it in the name of the person who arrived first at the meeting most often. Since charitable contributions are tax deductible in many countries, this gives incentives for being early and for not being late. Or as Michel Biron pointed out, it was both “carrot and stick.”
- Give everyone who was prompt for each daily scrum a reward like a two-hour lunch or permission to come in late and leave early one day.
- Everyone who was on time for each daily scrum goes to a movie during the day, one day during the next sprint.
- Establish a policy of “if one of us is late, we’re all late,” and then provide a significant team reward to everyone if everyone is on time. One person told me he did this, but extended it to include being on time for all meetings. He knew that it would be hard to do, so he needed a significant motivation and they agreed on a nice lunch paid for by the company. As a consolation prize, if team members were only on time 90 percent of the time, everyone would receive a chocolate bar.
I was told, “The result even surprised me. The team completely shifting their behavior. I was seeing team members loading up the digital agile board and setting up the conference connection for the remote team members minutes in advance of the standup. The team was holding each other accountable by friendly shoulder taps to make sure they all make it on time. I even observed a team member running across the building to grab someone out of a meeting to make sure she also makes it on time as well.”
- Ice cream if everyone is on time every time.
- A photo of the team holding a sign saying: “We did it!”
- Start the meeting 15 minutes before everyone wants to go to lunch. Viktor Buzga reports that the company cafeteria in his company gets very crowded at 11:30 when it opens. Arrive at 11:30 and there’s no wait for lunch. Arrive two minutes later and there’s a 10-minute wait. So he starts daily scrums at 11:15. If the team finishes in 10-12 minutes, they’re perfectly timed for lunch. If not ...
So, there are many ways you can go about this. And, as I said in my emailed weekly tip, I love getting the chance to learn from all of you. I definitely learned some good techniques from this. Also, I’ve learned that I really should think more about incentives rather than deterrents.
Whatever you choose to do, you really need to make sure the entire team buys into it. The last thing you want is for someone to go to human resources complaining that you’re making him do a pushup for every minute he arrives late to a meeting.
But, for a team on which being late is a problem, these approaches can help address the problem. A common thread in many replies I received was that many of these incentives and deterrents work especially well because the entire team starts holding each other accountable. This is a huge benefit over just a Scrum Master holding people accountable.What Do You Think?
What’s missing? What other techniques have you tried to encourage people to be on time for daily scrums? Please share your thoughts in the comments below.
- Strong partnership gets agile teams up and running four months ahead of schedule
- Deep knowledge to help people at all levels adopt agile and lean practices
- Extensive functionality to ensure business alignment and team collaboration
As part of a large agile transformation initiative, one of the largest agribusiness and food companies in the U.S., needed an experienced consulting team and an agile ALM platform that could help them reach their goal of getting more than 25 agile teams, across several delivery groups, up and running over a 12-month period.
The company needed assistance with constructing a plan, and coaching the teams while working with executives through the process change. Since the company was using disparate systems, they also needed one platform that could help them manage initiatives across the organization, break the work down across multiple teams and programs, while ensuring alignment with business goals. At the same time, they needed a way to foster better collaboration across the teams with different agile work styles.
The company engaged with trusted partner, Collaborative Leadership Team to evaluate how VersionOne Lifecycle could support the overall rollout plan at all levels. After an evaluation of many agile ALM vendors, the company selected VersionOne for the team’s responsiveness, as well as the extensive platform functionality that would help their teams easily adopt and scale agile across the organization.
The partners quickly engaged with the customer’s delivery teams and groups to implement the joint solution and get the company’s agile transformation started. The Collaborative Leadership Team had deep knowledge of how to apply agile principles and how to support people in adopting agile and lean practices. And with VersionOne Lifecycle, the company gained the ability to successfully plan, track, collaborate, and report within the platform, so that everyone could have visibility into the work being delivered. In fact, one of the managers said, “The TeamRoom just blows the socks off of navigating in Rally. We needed an easy way for teams to get the information they needed.”
Working together, Collaborative Leadership Team and VersionOne were able to get all of the teams and delivery groups to a stable and productive state four months ahead of schedule. It was fantastic to see how the consultants became trusted and well respected advisors throughout the organization, while allowing the teams the ability to be self-reliant and to continuously improve on their own. At the same, it was great to see how people at all levels in the organization were able to start using the VersionOne and start seeing the results of a successful implementation right away.
The post VersionOne & Collaborative Leadership Team Partnership Accelerates Agile Adoption appeared first on The Agile Management Blog.
I recently wrote a blog post addressing the fallacy that Project Managers are not needed in Enterprise Agile transformations. Reflecting on that post, it got me thinking about other misconceptions I’ve seen and am regularly asked about by my clients. Here are the ones I hear the most, and my attempt to clear up some common misconceptions.Fallacy #1: “We don’t need documentation, we’re Agile!”
This fallacy I hear all the time. It stems from the Agile Manifesto value “Working Software over Comprehensive Documentation”. Many people read that and believe that we just want to code and not provide documentation. What this actually means that it is more valuable to see working, tested software instead of spending a lot of time documenting up front. It DOES NOT mean no documentation.
In many organizations, long-lived documentation is important. It lives beyond initiatives to provide value in the future. This value can be in personas, meeting audit requirements, understanding design decisions or system requirements. Documentation can also be embedded in code, in automation and test cases, or in visual specifications. The important thing I coach is to focus on providing documentation that is barely sufficient. The goal is enough documentation to provide a shared understanding and no more. Anything beyond that tends to not be useful. No one is going to read giant documents that sit on the shelf gathering dust!Fallacy #2: “Agile means we will be faster from day 1!”
I hear this one often as transformations begin. Clients will try to compare what they completed in a year pre-Agile to what they are delivering now. This, of course, is trying to compare apples and oranges.
What Agile does a good job of is focusing on delivering the most valuable work first and driving risk down early (instead of waiting until the end of the project). We don’t want to try to deliver everything we did last year. We want to deliver the highest value items quickly and use feedback to course correct.
Over time, stable teams, automation, and process improvements will make teams faster. But, you may actually feel like you’re slowing down in the beginning. Focusing on value prioritization and high quality reduces rework and gets your product to market faster.Fallacy #3: “It’s been 3 months…we’re done!”
Repeat after me, “My Agile Transformation will never be done!” This is an important concept to understand. You will always be assessing. You will always be improving. It is a continuous cycle that never ends.
The world is advancing at an incredibly rapid pace. If you stop to rest on your laurels, someone will pass you by – and you could be synonymous with “Blockbuster” or “Kodak”. One of the key concepts we implement is sustainability of your transformation. Many Agile transformations fail because they don’t have the internal support and mechanisms to progress forward beyond the initial stages. This is the new way of life!Fallacy #4: “We will never be able to deliver in 2 weeks!”
If you are traditional waterfall organization, going from 8-12 month release cycles to 2-weeks Sprints can seem daunting or downright impossible. You can absolutely get there, but it won’t happen overnight.
Enterprise Agile transformations take time. And you will need help. Defining an end state vision, implementing a structure, governance, and metrics will set you on your path. Form, train, and coach teams in agile practices will begin to change the way you deliver. Use metrics to assess your system of delivery and make changes to reduce your batch sizes and optimize flow of value. Begin automation and DevOps efforts and identify and decouple your dependencies.
Change is hard. It can be uncomfortable. When things get stressful, we want to revert to we are comfortable doing. But, if that worked, why are you transforming?
We’ve all heard the definition of insanity – “Doing the same thing over and over while expecting a different result.” Real change is going to mean doing things differently. It doesn’t need to be many changes all at once. In fact, I like to make small changes, measure progress, and adapt to things that are not working.
At scale, we can’t be Agile by being structured the same way. It is going to require change, organized around products or value, bringing people together on cross-functional teams, breaking down work into smaller increments.
Remember, we’re cultivating something special when we adopt Agile. Reverting back to your old ways of working will diminish your results and produce bad habits. Make sure you have a clear vision, defined end-state, and good communication as to why it is urgent to truly drive change. Focusing on the “Why” will help align the organization behind that change.
In one of my workshops I explored how to use agile and Scrum beyond software development, for example in marketing, sales, support and in management. I gave this workshop in-house for a client to an audience which was not directly involved in software development. Many good ideas came up when preparing and giving this workshop, in this post I’m sharing them with the agile community.
Over the years I’m using agile principles and practices from Scrum beyond software development. For example, I do process improvement with agile, use Scrum for process improvement, reduce process debt with agile, manage projects using agile, and use agile to prepare and give training and workshops. I wrote about the golden rules for agile process improvement. I was also involved in eduScrum, an initiative where Scrum is used by students for education at school.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
After giving a keynote at the 1st Conference in Melbourne I watched a talk from Eduardo Nofuentes about adopting agile beyond software. He slightly modified the agile manifesto to broaden it’s purpose while keeping the original thoughts:
We are uncovering better ways of working by doing it and helping others do it. Through this we have come to value:
Individual and interactions over processes and tools
Outcomes over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I’m convinced that agile can be applied in many different areas. But, the information supporting this is scattered and sometimes hard to find, and that makes it difficult to use it and apply agile in other areas. Then the opportunity arose to bundle stuff … Help from the Scrum Master Community
A client asked me to give a workshop about agile to an audience which was outside software development. Explaining the agile manifesto and concepts from Scrum in my opinion wouldn’t be enough. I wanted to show actual examples of using agile beyond software, both from my own practice and cases published by others.
I used my network and posted a question on Facebook in the Scrum Master Community:
I’m preparing a workshop on agile/Scrum for non-IT. Anything that I should include, like experience reports, reference websites, checklists?
I got a lot of good ideas and experiences, which are in my workshop, next to what I do with agile and Scrum. In return for the contributions I promised to publish an overview of the workshop; to share an extract of my sheets which includes examples from using agile and Scrum beyond software development. Well, here it is:
A big thanks to everybody who provided ideas, on Facebook or directly, or by publishing examples on the internet on how they used agile and Scrum. All of this is very inspiring, and helped me to compile the sheets for the workshop which helped my client to take the first steps towards increasing their agility. Tailoring to use agile and Scrum beyond software
Of course you have to tailor agile and Scrum to support your needs. This is true when you use them in software development, but even more if using them beyond. Things to consider are:
- Deliveries & Goal: What is it that you want to reach? Which agile principles and Scrum practices can help you to get there? How?
- Custumers & stakeholders: Who do you have to involve to reach your goals and be able to deliver?
- Team & collaboration: How do you want to work together? What needs to be arranged to make it possible?
- Define “Done”: Which criteria need to be satisfied before something is good enough to deliver? Which existing processes and practices can be used?
- How to get feedback: What can you do to know if you’re moving in the right direction (or not)? Which feedback do you need, from whom?
Summing up: Yes, you can certainly use agile and Scrum beyond Software Development. The agile mindset and principles are general enough to use them in many areas. Share your experiences!
There are many good examples available. I’ve listed the ones I know, but there are probably many more. Please share your experiences by commenting to this blog post if you have used agile and Scrum outside software development. Let’s collaborate to learn from each other, and help people around the world to improve their way of working using agile and Scrum!
If integration with another software tool is absolutely essential to your work, you’ll be happy to hear about our latest partnership. You can now synchronize your Targetprocess account with any tool on Tasktop Sync, including Atlassian JIRA, Microsoft Team Foundation Server (TFS), GitHub Issues, Zendesk, HPE Quality Center, Bugzilla and more. You can find a full list of possible integrations here.
This means that if you or any of your teams are using a separate tool or software infrastructure for their work – perhaps for quality assurance, product support, ALM, or PPM – you can use Tasktop Sync to automatically synchronize data between the multiple solutions. Teams can work with the tool of their choice, without having to waste time manually transferring and standardizing information.How will this help Targetprocess users?
Let's start with an example: You and your company have just made the switch to Targetprocess, but QA has requested another year with their current tool. You can use Tasktop Sync to link entities in Targetprocess with whatever artifact is used to represent bugs in your QA team's tool.
This kind of synchronization allows Targetprocess to show the real-time status and priority of work items, and can also help your teams maintain flow and traceability. Keep in mind that this is just a singular example; Tasktop Sync can do far more than just synchronizing cards. You can link an entire software infrastructure to Targetprocess, if need be.
- Seamlessly & bi-directionally integrate with other PPM, Agile planning, requirements management, test management, and service desk tools
- Save time by eliminating the need for import-export of data and manual standardization of information between tools
- Synchronize artifacts across the lifecycle
- Reduce time to market with better flow and traceability between tools
- Get real-time data for faster and more informed decisions
- Keep all teams on the same page, even if they work from different tools
To get started with Tasktop Sync, go to the Tasktop website and fill out this form. For an annual fee (the amount of which depends on your requirements), they will sync your Targetprocess account with the tools or infrastructure you require (if the software is included on Tasktop Sync’s integration list). You can view Tasktop’s installation guide here.More information on Tasktop
Tasktop is a market leader in the Software Lifecycle Integration market. Unlike other common integration providers, there is no charge each time an integration is used, making this solution ideal for users who require in-depth infrastructure synchronization or are frequently switching between tools. The service helps to improve end-to-end traceability for companies that use multiple tools for collaboration or infrastructure.
Notable Tasktop Features:
- System administrators can integrate software tools through a graphical interface that lets them create, maintain and monitor integrations – with no programming.
- Differences among data types, text formatting, and even very complex relationships among artifacts are handled right out of the box.
- ALM tool users never see Tasktop Sync and don’t leave their tool of choice; artifacts are synced automatically without manual intervention.
- New releases from tool vendors are supported almost immediately. Tasktop’s test lab catches API changes as soon as a SaaS release is rolled out.
- Tasktop’s change detection algorithm does not overburden endpoint systems; performance is not gated by the number of artifacts synched.
- Tasktop can handle simultaneous updates and conflicts resulting from differences in workflow rules among endpoint systems.
- Operates even when endpoints are disconnected or offline.
- Can be used with on-premise, on-demand or hybrid infrastructures
- Tasktop’s integrations are bi-directional, easy to deploy and configure.
For more information, please do not hesitate to send your inquiries to email@example.com, or post your questions and comments below.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]