If the leading business literature from the past couple of years is to be believed, leanness and agility have become must-have characteristics of any company that expects to thrive. Yet, lack of executive support is consistently reported to be a primary reason that enterprise agile transformations are unsuccessful.
How can this be? If agility is essential to an organization’s business success, how can executive-level support of the adoption of agility throughout the enterprise not be a top priority?
As perplexing as that is, here are some things we do know:
Just the Facts
- Executives have limited time to take on more.
More than 60% of the executives surveyed by the Standish Group reported that they spend less than 5% of their time on executive sponsor responsibilities related to the projects that they already own.
- Executives aren’t focused on the same things that most agile practitioners talk about.
When is the last time you heard your CEO talk about ATDD, story point normalization, or team empowerment?
- Executives are accountable for business outcomes.
Growth, profitability, cost containment, and business strategy development rank high on the list of things that keep CxOs awake at night.
The struggle these days usually isn’t in convincing executives of the general benefits of agile. By now, they’ve at least heard about it or read about it. The challenge lies in connecting agile values, principles, and practices to their needs in a compelling-enough way to convince them that leading fundamental change in the way their organization thinks about and goes about its business will be worth the effort.
Most agile champions and practitioners have limited opportunities to influence executive leadership. And when the right circumstances have presented themselves, we typically haven’t done a very good job of advocating agile as a means of achieving business outcomes. In order to gain enthusiastic executive support, we’re going to have to maximize our opportunities by effectively talking about agile in the context of their needs and responsibilities. They won’t be into agile unless there’s something in agile for them.
Reframing the Discussion
You can use the three-component approach below to help you talk about agility more effectively at the executive level. This can close the perceived gaps between agile’s capabilities and the challenges that executives are focused on. The three components are:
- Message (a relevant statement of the challenge): says “I understand your needs”
- Methods (what we can do to meet the challenge): says “I can help you”
- Measures (how we’ll know that what we’re doing is working): says “I can prove it”
Message: “I understand that you’re frustrated at how we consistently plan more than we can do, which leads to unrealistic expectations and missed deliverable dates.”
Methods: “Why don’t we limit our commitment to how much we’re really getting done? That way, we can set realistic expectations as to how much we can deliver within a given time frame, at a given level of quality.”
Measures: “We can use the observed velocity trend to determine how much we can commit to. We’ll continuously update that trend, and investigate the causes of any negative trending.”
That’s just an introduction to velocity-based planning, and applicable to somebody directly involved with planning and delivering software. But in order to get the attention of executive leaders, we have to communicate in terms that really impact their world.
The skeleton of that discussion looks like this:
Message: “I understand that we are facing [higher-level business challenge]…”
Methods: “[these agile practices] can help. Here’s how it typically works [no agile jargon – use their language]. Here’s an example: [quick example of what ‘xyz company’ did]”
Measures: “These are the simple metrics we can track to know that it’s working…”
Here’s a fleshed out example:
Message: “I understand that we are facing increasing costs of developing our software, and that this is impacting our overall profitability. A significant factor in this is the amount of test and re-work churn we have during the development cycle.”
Methods: “Test-driven development and continuous integration can help reduce that expensive churn. The development teams continuously build and test small changes in a version of the finished product, allowing them to immediately catch and correct anything that isn’t working the way it should. That eliminates long, expensive integration and test phases. XYZ Company adopted these practices and reduced their overall cost of developing software, while gaining higher quality, and increased sales. And they achieved that without having to hire additional people.”
Measures: “In order to verify that our efforts are working, we can measure the trend in feature cycle time – how long is it taking us to get features completed and delivered to our customers? We can also track the trend of how many defects we are releasing to our customers. Both trends should go down.”
Now I realize that some might see this as a myopic approach, too focused on a particular set of practices and not focused enough on the values and principles behind them. Remember, though, that if questions are asked, there’s nothing preventing me from, say, further explaining the impact of these practices on throughput and how that affects both the revenue and cost components of the ROI equation. What I’m trying to accomplish here is simply flip the light switch on. We can talk about voltage, current, resistance, and luminosity later.
Of course, the flawless execution of this technique won’t guarantee that the executives in your organization will become agile fanatics. But they certainly won’t embrace agile if they don’t perceive it as a means of meeting their business challenges.
The point here is to be prepared with the right message, and with the methods and measures to back it up, when the opportunity to influence your executive leadership presents itself. Give it a try, and let me know how it goes!
Placeholder stories, in general, are a bad idea. Estimating placeholder stories to reserve capacity or to get credit is a very bad idea.Define “Placeholder Stories”
Of course, all stories are “placeholders for a conversation”, but that’s not what I’m talking about here.
I am also not talking about things like “Refactor the such-n-such class as we start work on the something-or-another Epic”. I’m not talking about having a known customer problem but not yet knowing what to do about it, if anything. Those are specifically identifiable work. Those should be in the backlog (for the sprint or the release), and I don’t call them placeholders.
I’m not wild about having time-tracking stories in the sprint or release backlog because they need to be backed out of certain metrics such as number of stories completed (throughput). But I understand why organizations have them. Let’s call those time-tracking stories instead of placeholders.
By “placeholder stories” what I mean are stories for known-unknowns (or even unknown-unknowns) such as:
– we know we’ll have some production support work to do… 2 points
– we might have to do some sales support… 1 point
– we know we’ll have to do deal with some high priority defects that come up during the sprint… 3 points
– we could get interrupted for some high priority expedite work… reserve 8 points
– the build server is flakey and it might break again… 2 points
– “placeholder story for other unknown work that we might have to do”… 3 points
– end of release regression testing… 60 points
My main complaint is estimating them.Visibility is Good
I’ve seen teams put a placeholder story in each sprint just as a place to keep record of their customer calls (mainly to get credit). They’ll add a line in the description or a (sub-)task for each new support call. I’m not completely opposed to the placeholder story itself in this case because it’s really just another type of time-tracking story. Also, making the work visible with sub-tasks is a fine idea. But estimating it is wonky.Negatively Impacts Release Planning
Velocity is a useful input to sprint planing, but it is far more important and useful for release planning. If velocity includes defects and other placeholders, release planning actually becomes more difficult.
Keeping up with how much of the velocity the PO could bank on and how much will go to defects and other placeholders gets tiresome and is error prone.
When the Product Owner is considering the cost or duration of a batch of stories (for example, a new feature or an epic), that PO can’t just do simple math (backlog size / velocity). They have to ask someone to put placeholder stories for support work into the epic or they have to ask someone to tell them what’s the velocity of just the real user stories.
Placeholders make it harder to do what-if scenarios for the release: “What if we trimmed some scope and brought the release date in 2 months? What if we do this expedite and extend the release 1 month?” We have to consider where the placeholders fall in the backlog and scale them up or down. Or if there is a placeholder slotted in advance for every future sprint, then we have lots of placeholders polluting our backlog.
Estimating placeholders causes your velocity to be inflated relative to the backlog of known work for the release. Not estimating placeholders for known-unknowns will simplify release planning.
Therefore, don’t put placeholder junk in your velocity. If you use velocity or throughput for release planning purposes, and you probably should if you are making any release commitments at all, then your velocity metric should only count value stories — items in the backlog that the Product Owner or Customer wants, items from your story map and your Epic/Feature/Story decomposition.Not Needed for Contingency
Some people use estimated placeholders for buffering in a release plan. They have to do this because they put points on everything, on all the unplanned stuff too. Don’t estimate that stuff. The unplanned and unknown stuff should serve to lower your velocity.
Track the historical rate of production support separately from your velocity. Track defect rates too. Understand the trend and distribution pattern across a release. Then take that into consideration when putting the release plan together. For example, that information helps me decide what to use for my planning velocity, how many or which sprints to include in the average and whether to adjust it further. It also helps me decide how many sprints of active development to plan for. If you take a week or a couple sprints at the end of your release to do regression testing, just plan for that in your schedule. You don’t need to put points on it.
Moving placeholders around as release dates change and adjusting them as the buffer is consumed gets tiresome. Worse, it’s a complication that creates unnecessary opportunities for error.
Plan releases conservatively: don’t include known-unknowns in your velocity; but do include known-unknowns in your release plan.Not Needed for Sprint Planning
Usually when teams use placeholders it’s because they want to estimate story points for that work in order to reserve some capacity in the sprint. Putting a placeholder in every sprint and calling it 2 points to reserve capacity is unnecessary.
Plan sprints based on the amount of planned points of stuff the Product Owner wanted that you got done in the last sprint. If you use (sub-)tasks with hours estimates and an hours-based burndown, then reduce your capacity for these unknown things, but base it on how many planned hours for known-knowns you were able to do in prior sprints.
If your build server is flakey or if you need to do some maintenance on your VM server, either decide to fix it or don’t. Don’t put a placeholder in your sprint just in case. That’s poor planning.Isn’t Relative Estimation
Relative estimation works when comparing like kinds of work — known-knowns and actual user stories. You don’t know how many production support issues you are going to have or how long it’s going to take to resolve them. Estimating that stuff is much less accurate than estimating known-knowns. General production support and other overhead shouldn’t show up as estimated items in your sprint or release backlog. Just let support activity be a drag on your velocity.What About Defects and Expedites?
Defects should show up in your backlog once there is a specific issue that needs fixing — a known-known. Same for high priority expedite work. Add it to your sprint once it becomes a known-known.
But don’t estimate defects. Just let them be a drag on your velocity. Track the historical rate of defects separately. You can reserve capacity in your sprint and release plan without putting points on a placeholder for defects that haven’t been discovered yet.Getting Credit for Work Done
If your team is using and estimating placeholders to get credit, Stop that. It’s a dysfunction in the organization if people feel the need to inflate their velocity or get credit.Conclusion
There is no good reason to put points on placeholder stories. Keep unplanned stuff out of your velocity number. This leads to simpler and more conservative release planning.
My dad, even with a serious head injury that ended his working life, regularly attended a computer club where he could chat with a community of fellow geeks who accepted him head injury and all. I was always glad he had somewhere he could be accepted, but I never realized I’d end up attending and helping to run programming user groups in my own career.
I first went to a Java Users Group in Sacramento, SacJUG. I had been getting deeper into Java and figured it was time to see what the local community was like. I found a home with some fellow geeks and I attended regularly for the next ten years or so. I even eventually hired multiple developers I met at SacJUG and I appreciated being able to geek out on the language and share war stories. A few years later I got deeply into Ruby in my spare time with the advent of Rails and eventually helped setup the Sacramento Ruby Meetup. It would be a few more years until I got paid to do Ruby, but met some great developers along the way and I still regularly attend. Only a year or so later I helped found the Sacramento Groovy User’s group which continues today as essentially a JVM languages group.
All this experience with user groups has led me to experiment with visiting other user groups from time to time. A few months ago I showed up for an Angular group and met a lot of front-end specific developers I don’t mix with regularly.
If you haven’t tried out attending a user group I encourage you to try it. It only costs you an hour or two and the benefits are worth it. Things like:
- Seeing the size of say the node.js community in your town and getting a sense of how a new language or toolset is catching on.
- Getting exposure to something new with a group of programmers.
- Meeting fellow developers who are trying to come up to speed or stay on top of technologies.
- Finding a great new candidate for your shop. The developers who regularly attend user groups tend to be more motivated and engaged employees and you can get a pretty good sense of their skills just from chatting.
- Getting out of the house since many of us are introverts. With the shared context it’s much easier than say the annual holiday party.
- Practice speaking if you work up the nerve in a low stress atmosphere.
- A sense of whether a particular language/community is on the rise or fall.
Without a shadow of a doubt, a product backlog is one of the most important things when we talk about an agile way of software development. Backlog is a place where all your product requirements should be stored. These requirements are called PBI – Product Backlog Items.
Backlog is also a tool that can help your team with proper planning. Its aim is to:
- facilitate your team with delivering the greatest value possible
- ease workflow and track work progress
In this post, we would like to devote our attention to product backlog. What are the good product backlog features and how to use them.
Ok, sit comfortably in your chair and let’s walk through the world of agile product backlog! Enjoy the read!
1. A good product backlog is ORDERED
Simply speaking – the items are arranged in order of execution.
Priority is significant here, which means that two different items cannot be equal with regards to importance – one needs to be precede the other (closer to the top of the backlog).
Backlog is also the only place where requirements are stored. Therefore, before we place any new requirement we must fully consider its value and importance.
A product owner is a person responsible for arranging the backlog and putting the items in the right order. Product owner should aim at stacking the requirements on the backlog, so that with every iteration a new version of software can be delivered.
We should keep one thing in mind when we talk about product backlog. It can be organized in a variety of ways – everything depends on the context!
2. A good product backlog is RELEVANT
Contains items relevant to the current requirements and needs.
A brilliant and very useful benefit of the agile way of software development is that it allows us to constantly check whether our product corresponds with the expectations. If not, we can just adjust it or change it (with regards to the Inspect&Adapt rule). It’s as simple as that :)
As you can see – in order for backlog to stay relevant, it cannot be static. We could even say…
Click To Tweet
3. A good product backlog is TRANSPARENT
It’s visible and legible to all those parties involved.
Backlog can be adjusted when needed. However, it can only be done easily when it’s transparent and all interested people can get acquainted with it and understand it well.
It’s way easier to talk about some items and their importance with product owner (and maybe convince him to move our awesome feature to the top) when it’s clear and legible.
It’s absolutely great when a backlog item has a format of a user story:
As a [role] I want [a goal], so that [benefit]
This format not only facilitates the creation of requirements that are intuitively understandable for all concerned but also it tends to think in terms of the users needs.
4. A good product backlog is REFINED
The level of detail is adapted to the requirements of its position in the backlog.
A refined product backlog is one where requirements are adequately sized up to their position. Moreover, all requirements on top should be clear and well understood and ready to planned on.
This characteristic can save us a lot of time and unnecessary effort. Because of that, we can avoid a situation where we see huge, vague requirement on top of our backlog, where the team spent lots of time analyzing it before starting a new iteration.
Good product backlog should have a pyramid structure – a number of very small (decomposed) requirements on top, increasing requirements somewhere in the middle and keeping large, general ideas on the very bottom.
It’s rather obvious that those requirements that are on the top should be small enough to be performed in next sprint.
One more thing…
There are many ways to manage requirements and backlogs, it depends on various factors like product type or product lifecycle. A lesson that we need to learn is that we should stay flexible and open when thinking about choosing the right way, relevant to our needs.
One of the first things we recommend new Agile teams establish is what’s called the “Definition of Done”. The DoD is crucial to highly functioning Agile Teams in helping them develop practices and behavior that drive quality, consistency and transparency.Why it matters
A useful product has two key aspects. Features in this product are [...]
Last week, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla presented a webinar about “Fast IT,” a new way of managing rapidly changing and Agile projects in areas like mobile, Web, analytics and marketing applications, while working smoothly with reliable core systems ("Core IT"). Andy discussed the dynamics of Fast IT, and Sid presented a case study of how Attivio spun up a major Business Intelligence app in two weeks with two people.
If you missed the webinar, view and download the slides.
Want an overview of Fast IT in 60 seconds? Watch the video below:
Get notified about new and exciting content around Fast IT by completing the form below:
Paying for your Assembla subscription with PayPal has never been easier. We recently added the ability to set up recurring payments with PayPal that will automatically pay for your Assembla subscription every billing period, whether that be monthly or annually. Previously, it was a manual process that required logging in and paying every time an invoice was created.
To set up automatic payments with PayPal, visit your billing page > select the PayPal option > and follow the steps.
If you have any questions or issues, please contact Assembla support at email@example.com.
If your team uses Slack, HipChat, Flowdock, or Bigplans for communication, we have added preconfigured webhooks to make setting up these integrations painless. Once configured, you can selectively manage the Assembla events that are posted out to these apps, such as ticket activity, commits, deploys, etc., to monitor project activity in real-time, inline with other team communication.To get started, click on the desired integration below:
Ripple is a protocol for value exchange that makes it easy to transfer and trade fiat currencies, Bitcoin, or XRP - the native asset of the Ripple network.
Assembla is giving away 1000 free XRP (the Ripple native cyptocurrency) to any person with software development skills who is interested in learning about Ripple development. Get it here: https://www.assembla.com/ripple
I called Ripple Labs a few months ago to find out more about ways that their "gateway" can help us pay developers in many different countries. Essentially, we do banking for the developers on our global team. We pay internal accounts, hold the money until they ask for it, and then transfer money to them by bank wire, ATM/Payoneer, or other mechanisms. We have found that the bank wire system is embarrassingly slow and unreliable. This is the problem that Ripple is trying to fix. Their gateway is like a bank in an open-source box. It keeps accounts in any currency, including USD, other currencies, XRP, and Bitcoin. It can transfer those accounts instantly and reliably on the shared "ledger." It is also gaining exciting new features such as "multi-signature" which enables outsourcing and crowdsourcing customers to post a budget amount, and then transfer it to their hard-working suppliers through an arbitrator.
Now I am working more closely with Ripple to help them scale up their development process. I decided to make this free XRP offer for two reasons:
- Users need 20 XRP to activate a Ripple wallet. We want to remove the hassle from acquiring the XRP so new developers can get started.
- We want to build an email list of developers that might be interested in working on internal development, bounties, or bank integration projects.
If you use Assembla and Bigplans, we have added a pre-configured webhook making it easy to post Assembla events out to your Bigplans chat room. Check out below for configuration instructions.
Bigplans is a simple, integrated way to manage a distributed team. It includes a "lean" task board, real-time chat, and a unique "advisor" (a real person) that helps you get on-demand resources if you need them. For programming teams, it includes a tight integration with Assembla login and Assembla tickets.
You can use the Webhooks tool to feed Assembla events into any of your team chats. To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.
Once installed, click on the Webhook tool in your main navigation and select Bigplans from the list of pre-configured post options:
You will need to obtain and update the auth token in the “Content” section.
To obtain your Bigplans auth token:
Visit Bigplans and navigate to the plan you want to post Assembla events to. Click on the ‘Connect’ option in the top bar. Under the “Message API” section, there is a section called “API Token” that will display your token. If no token is set, click on the ‘Reset’ button. Copy the token ID and replace the “BIGPLANS_AUTH_TOKEN” in the Webhook tool.
Now configure what Assembla events you would like to post to your Bigplans chat room and click ‘Add and Authenticate.” Don’t forget to enable the configuration under the “Title” field.
Your Assembla events will now be posted to the configured Bigplans chat room:
If you use Assembla and Slack, we have added a pre-configured webhook making it easy to post Assembla events out to your Slack chat room/channel. Check out below for configuration instructions.
To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.
Once installed, click on the Webhook tool in your main navigation and select Slack from the list of pre-configured post options:
You will need to setup an incoming webhook service integration within Slack to obtain your token. To do this, visit https://YourSubdomain.slack.com/services/new/incoming-webhook, select the desired channel to post to, and click ‘Add Incoming Webhook.’
Once created, copy the provided Webhook URL and update the External URL in Assembla’s Webhook tool.
Now configure what Assembla events you would like to post to your Slack room/channel and click ‘Add and Authenticate.' Don’t forget to enable the configuration under the “Title” field.
Tip: Within the Slack “Incoming Webhook” page that you set up for this integration, you can scroll to the bottom of the page and expand the “Integration Settings” where you can add a label, change the post-to channel, and change the icon and name for your webhook bot.
Your Assembla events will now be posted to the configured Slack room/channel:
If you use Assembla and HipChat, we have added a pre-configured webhook making it easy to post Assembla events out to your HipChat chat room. Check out below for configuration instructions.
To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.
Once installed, click on the Webhook tool in your main navigation and select HipChat from the list of pre-configured post options:
You will need to obtain and update the auth token and room ID in the “Content” section.
To obtain your HipChat auth token:
You will need to visit https://YourSubdomain.hipchat.com/admin/api and enter your password to access the “API Auth Tokens” page. Under “Create new token” select ‘Notification’ type, provide a label, and click ‘Create.’ Copy the token ID and replace the “HIPCHAT_AUTH_TOKEN” in the Webhook tool.
To obtain your HipChat room ID:
Visit https://YourSubdomain.hipchat.com/admin/rooms and click on the desired room you would like to post Assembla events to. Copy the App ID and replace the “HIPCHAT_ROOM_ID” in the Webhook tool.
Now configure what Assembla events you would like to post to your HipChat room and click ‘Add and Authenticate.” Don’t forget to enable the configuration under the “Title” field.
Your Assembla events will now be posted to the configured HipChat room:
When we at Assembla heard about the 2-2-2 project structure used by Attivio, we knew we had a fun story and a big idea to share. The fun story is the way that Attivio can spin-up major Business Intelligence apps with 2-day, 2-person prototyping sessions. The big idea is “Fast IT”: a way of managing fast and Agile projects, while working smoothly with your slower, more reliable core systems: "Core IT".
In this Webinar, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla, will share their discoveries about ways that “Core” and “Fast” can work smoothly together. We will show tools that help you wrap and index your Core IT so that you can easily use it in Fast IT projects. And, we’ll show how to professionally launch and manage an expanding portfolio of Fast IT projects for analytics, Web, mobile and marketing applications and SaaS integration.
This Webinar is designed to help IT professionals or project managers who are handling analytics, Web, mobile, cloud and marketing applications.
Garrigan Lyman Group was worried about losing the loyalty of its own customers. The agency was expanding rapidly and tackling more complex e-commerce, mobile, social media and video projects. Clients had no visibility into when new requests would be delivered. Development managers were having trouble tracking releases and matching resources to requirements. Teams needed a solution to prevent missing deadlines and ensure the quality of delivery.Objective
Chris “Whitey” Geiser, GLG’s CTO, knew that the agency could not afford to lose “customer equity,” the hard-won confidence that GLG could deliver innovative digital marketing solutions. So he and his team began looking for technologies that could help them centralize processes, manage development requests, and improve communications with clients.Results
Assembla has helped Garrigan Lyman Group win new business from existing clients. The solution has helped GLG evolve from helping clients with flashy but self-contained marketing projects, to solutions that work with the core of their businesses. It allows the company to collaborate better with clients and improve control of their development processes.
To see how GLG learned to work more closely with its customers,
fill out the form below to download the full case study.
It’ about time to give the Product Owner a chance to fight back. With the help of Heiko Weltin I created a list as a base for the revenge. I hope you’ll like it:
- Create your product backlog without any prioritization. In the end you need all of the features before you can bring the product to the market.
- Only create the headline of your user stories and don’t add any additional content, even if the team asks. You can’t prepare everything for the team.
- Only use two types of priorities: “Urgent” and “Can be done later”. Anything else would be a waste of time.
- Always promise release dates and scope to your customer without talking to your development team upfront. You are a skilled estimator.
- Always add one task to a user story that keeps the team from finishing it. The Definition Of Ready (DOR) is for wimps.
- Insist in long running sprints of at least four weeks. If the team has more time, more features can be done.
- Only prepare as many stories as needed to finalize half of the sprint. The rest of the time it is the task of the developers alone to clarify the rest of the stories.
- Only meet once a week with the team and keep this meeting as short as possible. You don’t want to hang out with those sissies.
- Always answer your phone during any team meeting. Don’t leave the room as the team shouldn’t be able to continue the discussion without you.
- Never attend the daily scrum. Instead, talk to single developers afterwards. This makes it easier to build pressure on them.
What do you think? Do you have some additions to this list? Feel free to add them in the comments.
It’s about time to nag the product owner, isn’t it. Fortunately, there are plenty ways to do this. To help you in your quest to do so I created a list of 10 proofed ways to drive your Product Owner crazy:
- Five minutes before the Sprint Review is the right time to tell your Product Owner that your team wasn’t able to finish anything. It is even more fun, if this was a planned release. Transparency is for milquetoasts.
- Don’t invite the Product Owner to any Scrum meeting. He is a chicken and you are the pigs, right.
- Ignore the Sprint backlog and work on the features you like the most. Who cares about the Product Owner’s vision?
- Assign all tasks that were created during your retrospective to your Product Owner. He is the root of all evil and responsible for all the problems in the project.
- Don’t attend the Sprint Review. You already know how your product looks like.
- Never show the real product in the Sprint Review. Instead, prepare a nice and shiny power point presentation.
- Never talk to the Product Owner if you have questions about a feature. Instead, implement it based on your favorite assumptions.
- If it is difficult to establish a stable communication to your Product Owner, define someone in your team to become the so called Product Owner proxy.
- Always break your release date promises. Everyone loves surprises.
- Question everything that is in the product backlog and try to start lengthy discussions about as many features as possible. At least, that’s what your mother told you.
Try this out and post your experiences in the comments. If you have additional ideas, feel free to add them, too.
The new year has just started and it’s time for the next steps to rile your team mates. So let’s have a look at one of the activities in Scrum that can be easily sabotaged: the retrospective. Here are 10 proofed ways to wreck any retrospective:
- Keep the retrospective as short as possible. No need to invest too much time in this meaningless gathering.
- Only focus on negative events and ignore any positive things. This is the only valid path to improvement.
- Handle a retrospective as any other meeting. Sit around a table and just talk.
- Ignore the complexity of the system around you. There is always a cause and effect.
- Always use crappy material such as cheap post-its that easily fall from the walls or old pens that hardly write.
- Forgo a facilitator for your retrospectives. It is only a burden and will slow the whole “meeting” down.
- Don’t use any agenda and deliberately ignore the retrospective’s phase model.
- Directly start with defining what has to be changed in the next sprint. Everybody already knows what has to be done.
- Never check if the defined tasks of the last retrospectives were done or even had the desired effect.
- Never bring food to your retrospectives. Hungry participants will do anything to finish a retrospective as fast as possible.
What else could you do? I’m looking forward to your suggestions in the comments.