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.
Now that the team is armed with new weapons, it is time to help the Scrum Master to fight back. If you didn’t read my first post on this topic have a look at the 10 things a Scrum Master can do to drive the team crazy blog post I wrote two years ago. Here we go:
- Get you own office, if possible in a different city or even country. Working at the same location as your team could be harmful.
- Count the number of finished tasks per team member and confront those lazy buggers with the obvious low performance.
- Try to restrict the communication with the team to Email only. You don’t want to hear their whiny voices.
- Don’t tell the team what you are working on. Transparency only applies to the rest of the team.
- Always cite the Scrum guide if members don’t stand to the Scrum rules. Continuous repetition will help raising the team’s understanding for this process.
- If a team member has a question, point them to Google. Google has all the answers, right?
- Ignore the Product Owner. It is his responsibility to create and maintain the backlog, not yours.
- Don’t attend the Sprint Review. It is a meeting exclusively between the PO and the team.
- Nurture your lack of interest about the product the team is building. This is something the PO has to take care of.
- Bring drums to the team’s office and play them like on a slave ship. Every good team needs a beat.
I’m looking forward to your additions in the comments
It’s been a long time since I wrote “10 things to drive your Scrum Master crazy” and it’s about time to give you some new weapons. So, here they are:
- Hide the SM’s beloved moderation markers.
- Play on your smartphone during the (planning) meetings, as long as they are not talking about YOUR tasks.
- Always lament about the same things but don’t change anything.
- Keep blaming and finger pointing everyone else except yourself for all the problems, you are only a victim.
- Ignore all agile values as they don’t apply to you.
- Simply ignore your Scrum Master, especially when he tries to coach you. Coaching is evil!
- Ignore the findings from your latest retrospective because you have more important stuff to do.
- Write as many things as possible on ONE post-it. Clustering is much more fun this way.
- Don’t put your tasks on the sprint backlog. Your Scrum Master is an evil micro manager. I swear. Transparency sucks.
- Ask your boss to put the Scrum values into the performance goals of every employee.
Scrum.org announced today that its Chief Craftsman, David Starr, will soon be joining Microsoft as Senior Program Manager in Visual Studio ALM.
Since joining Scrum.org in 2011, David has driven significant improvements in all of Scrum.org’s programs, and has dedicated himself to helping teams around the world improve their software development. David is leaving his post as Chief Craftsman for Scrum.org to help Microsoft continue improving Visual Studio to support agile software development practices.
In discussing his new role David said, “There is a saying that the tool sets the rules. As unfortunate as that statement is, it is true for many organizations who don’t yet value people over process and process over tools. I look forward to delivering products that encourage good agile practices with a focus on better people interactions and higher quality software. Creating features for a product that is used by millions of software developers is humbling.”
"It is with mixed emotions that we bid David farewell," said Alex Armstrong, Scrum.org's co-founder and VP of Business Development. "David has made incredible contributions through his work at Scrum.org, and we will miss him at each and every Daily Scrum. As part of the Scrum.org team, David has been directly helping to improve the profession of software development. We are excited that he will be able to continue to do so with a company as central in the software development universe as Microsoft," Armstrong continued.
“I have been privileged to work with the thought leaders at Scrum.org. The Professional Scrum Trainers and others in the Scrum community are some of the most committed and talented people contributing to our craft,” said Starr.
“I will miss my interactions, heated discussions, and finally resolutions with David.,” said Scrum.org founder Ken Schwaber. David drives integrity, and that is essential to Scrum.org’s mission and to the well-being of our profession.
Asked about the significance of Microsoft’s choice, Armstrong summarized, ”By bringing a Scrum practitioner with David's unique mix of talents into a leadership role on its flagship ALM product, Microsoft is clearly telegraphing its commitment to supporting Agile and Scrum teams. Agile’s influence in software development has been increasing steadily over the past decade, and this seems to be a clear demonstration of the trend continuing.”
You can read more about David’s future plans on his blog.
I never refer to the daily scrum (or daily standup) meeting as a “status meeting.” The term “status meeting” is too pejorative for most of us. For me it conjures images of sitting around a table with each person giving an update to a project manager while everyone else feigns interest while either mentally preparing for their own upcoming update or wondering how much longer the meeting will last.
I prefer to think of the daily scrum as a synchronization meeting. Team members are synchronizing their work: Here’s what I did yesterday and what I think I’ll do today. How about you? Done well a daily scrum (daily standup) meeting will feel energizing. People will leave the meeting enthused about the progress they heard others make. This won’t happen every day for every team member, of course, but if team members dread going to the daily scrum, that is usually a sign of trouble.
I want to offer one of my favorite tips for an effective daily scrum: If you’re a ScrumMaster, don’t make eye contact with someone giving an update. Making eye contact is human nature. When we speak, we make eye contact with someone. It’s only natural that a team member will look at the ScrumMaster; call it a legacy of too many years under traditional management but a lot of people on Scrum teams do look at their ScrumMasters a bit like managers to whom they need to report status. By not making eye contact with someone giving an update, the ScrumMaster can, in a subtle way, prevent each report becoming a one-way status report to the ScrumMaster.
Each person’s report is, after all, intended for all other team members.
I’ve never been a micro-manager, especially not since using agile and Scrum. I could have turned into a micro-manager early in career, except I’ve always been too busy to spend my time checking up on people. But, while I’ve avoiding checking up on teams or people, I’ve never been reluctant to check in with them. I was recently reminded of this by reading an article about the importance of small wins.
While checking up and checking in may seem similar, there are four key things a good ScrumMaster or agile project manager can do to avoid crossing the line into micro-management while still checking in on a team:
1) Be sure the team has the full autonomy to solve whatever problem they’ve been given. A good ScrumMaster ensures the team is given complete autonomy to self-organize and achieve the goal its been given.
2) Don’t just ask team members about their progress; offer them real help. ScrumMasters do this, for example, by protecting the team from outside distractions and removing (or even anticipating) any impediments.
3) Avoid blaming individuals. Things will occasionally go wrong. Assigning blame when that happens will make people feel they are being checked up on rather than just being checked in with.
4) Don’t hoard information. Micromanagers tend to view information as a resource to be retained and only shared when needed. A good ScrumMaster will share anything learned by checking in with others who could benefit from it.
So, stop reading this blog and go check in with your agile team right now. Just don’t check up on them.
I’ve been wondering lately if Scrum is on the verge of getting a new standard meeting–the Backlog Grooming Meeting, which is a meeting an increasing number of teams are doing each sprint to make sure the product backlog is prepared and ready for the start of the next sprint.
To see why a Backlog Grooming Meeting may be a few years away from becoming a Generally Accepted Scrum Practice, or what I call a GASP, let’s revisit the early 2000s.
Back then, Scrum didn’t have a formal Sprint Retrospective Meeting. Prevailing wisdom at the time was, in fact, fairly opposed to such a meeting. The logic was that a good Scrum team should be always on the look out for opportunities to improve; they should not defer opportunities to discuss improvement to the end of a sprint.
That argument was a very good one. However, what was happening on teams was that day-to-day urgencies took precedence and opportunites to improve often went either unnoticed or unacted upon. And so what most teams eventually realized was that of course we should improve any time we notice an opportunity, but at a minimum each team should set aside a dedicated time each sprint for doing so–and thus the retrospective became a standard part of Scrum. This was helped along tremendous by the great book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen.
I’ve had more CSM course attendees recently asking questions about a Backlog Grooming Meeting as though it were a GASP. Many are surprised when I tell them that not every Scrum team has such a meeting each sprint. I still don’t advocate every team conduct a Backlog Grooming Meeting each sprint–as with the early arguments against retrospectives, I’d prefer backlog grooming to happen in a more continuous, as-needed way–but so many teams are successfully using a Backlog Grooming Meeting, arguments against it may be on their last gasps.
Share what you think below. Will a Product Backlog Grooming meeting become so common it becomes a Generally Accepted Scrum Practice (GASP)?
Following the article in the Wall Street Journal on daily standup meetings a few weeks ago, a number of other places have interviewed me abut the topic. I don’t know why they’re asking me, but the interviews have been fun so far. The latest was on the National Public Radio (NPR) Marketplace show on Monday, 20 February 2012. You can listen to the whole show but Sarah Gardner’s interview with me begins at 18:50.
I’m thinking of buying a new car. So I’ve put together a list of cars to consider. Here they are in priority order:
- Bugatti Veyron Super Sports
- Pagani Zonda Clinque Roadster
- Lamborghini Reventon
- McLaren F1
- Koenigsegg CCX
- Porsche Carrera GT
- Aston Martin Vanquish
- Toyota Prius
- Toyota Camry
- Tata Nano
Unfortunately, though, I’m not sure I can afford my top priority car. So let me put some points on each car. I’ll start with the least desirable car and put a 1 on it, a 2 on the next car, etc. That reorders our list so with points on each car we get:
- Tata Nano
- Toyota Camry
- Toyota Prius
- Aston Martin Vanquish
- Porsche Carrera GT
- Koenigsegg CCX
- McLaren F1
- Lamborghini Reventon
- Pagani Zonda Clinque Roadster
- Bugatti Veyron Super Sports
Now I think about my personal spending limits and I can spend between $25-$50k on a car. I’d like to be closer to $25k but a good salesman might get $40-50k out of me. Since the Tata Nano (at one point) goes for about $2500 that means I can afford between 10-20 points.
So, looking at the list again and the points assigned to each car, I think I’m going to buy a Bugatti (10 points), a Pagani (9) and a Tata (1 point). Unfortunately, when I show up at the Bugatti dealer, I am somewhat informed that the Veyron lists for $2,400,000.
What went wrong here?
The problem is that points are not a ranking. When we rank product backlog (or car backlog) items we use ordinal numbers (such as first, second, third). We cannot add ordinal numbers together. We cannot say that the distance between first and second is the same as from second to third. The Bugatti in this example is not ten times the cost of the Tata.
Ranking stories (or cars) like this is worthless. We want story points to instead reflect the relative effort involved. For cars we could put points on as follows:Tato Nano 1 Toyota Camry 12 Toyota Prius 14 Aston Martin Vanquish 102 Porsche Carrera GT 193 Koenigsegg CCX 218 McLaren F1 388 Lamborghini Reventon 640 Pagani Zonda Clinque Roadster 740 Bugatti Veyron Super Sports 960
These points are of course based on the relative costs of these cars. I need to be able to do the math on these estimates that someone would want to do. Someone can afford 20 points on a car–which should they buy? Should I buy this item for 10 points or those other two for 5 points each? You can’t do that when points are assigned via a ranking.
Story points on an agile product backlog represent the effort to implement the backlog item. Since cost on most software projects is made up almost exclusively of labor (rather than buying parts), we can think of a story point estimate on the product backlog as being the cost, as in the car example here.
And, when I look at the relative costs here, I can tell I belong in the Toyota dealership rather than the Bugatti dealership.
The following was in response to Mark Hurst’s recent post How to change the CEO’s mind.
UX rarely has power in an org. Often, we must convince those who make decisions that to do what we recommend is beneficial to the company, their teams, and to them as individuals (not necessarily in that order). It’s a permission game. The more permission we are given, the better we are able to do our jobs.
Sometimes we have champions in the org that recognize our value and what we can deliver. Often there are those who at worst know the UX buzzwords and at best aren’t willing to give UX enough of a priority to be effective. Those are the cases where we don’t have much permission to act and can be frustrated at our lack of impact.
In these cases, a more modest approach may be necessary. Each additional bit of value we deliver and can take some amount of credit for will typically give us a little more confidence and permission until we have earned the trust of the one with the power. That can take time. Sometimes a lot of time.
A key decision as practitioners is whether it is possible to change this person’s perspective and if it can be done in a timeframe we are comfortable with in terms of our own growth and career (and whether there are other options available). I’m not saying quit as soon as you hit a wall with a stakeholder. Recognize that change takes time. Recognize that not everyone will change. Decide whether you have the patience to wear down the rock.
That being said, I agree with Mark. The transformations that stakeholders can have from seeing real users interact with their product can be amazing. However, as many commenters pointed out, you need to have permission to first do the testing and then for the stakeholders to trust you enough that they are willing to change their minds based on the test results in order for it to be effective. This is less about the techniques you employ then it is about your relationship with your stakeholders.
It's a new month, and now there is a new Scrumy feature for Pro users: The Scrumy API. Pretty much anyone who has asked us if we have an API recently has already been directed to that page and has been able to access it, but now we're sharing our secrets with the world.
For the uninitiated, an API is an interface that we give to you in order to access the data that we've stored for you in a convenient way. Essentially, it allows you to write your own programs that interact with your Scrumy projects. If, for example, you wanted a big red button that moves all your unfinished tasks into the 'Done' column, you could build that yourself with a few clever API calls.
The Scrumy API is divided into two separate parts: REST and Webhooks.
The REST API allows you to get data from your projects in XML or JSON form using simple URLs. You can also manipulate your data by POSTing or PUTing data to those URLs. You can read all about it at the REST API documentation page.
Webhooks are very different. A Webhook is a URL for an application that you have running on your own server which receives data from us. This means that any time you create or change a task, for example, we will send a piece of data representing the change on your project to that URL. A simple thing you could do with this would be to send a tweet any time you finish a task. Read more at the Webhooks documentation page. Also, the demo is set up to use webhooks, but it works a bit differently than your projects. The demo will allow you to enter 5 webhooks, but none of them will be active for more than 5 minutes. So, if you just want to see how webhooks work, feel free to use the demo, but unless you want to be a jerk, use an empty slot. Then you have 5 minutes to test your heart out.
So those are the big updates for now. If you find errors while reading the apidocs or feel that you could clarify something, feel free to update the documentation. It's a wiki for a reason. If you have any other questions or comments, feel free to contact us at email@example.com.
I had an interesting conversation with a manager the other day about how to gain more insight into changes that are ongoing in the application one of our pilot Scrum teams is working on. First, what’s the problem? Group A was doing independent regression for a release and uncovered some ”defects’ that were a result of changes in the application by our Scrum team. Truth be told, those ‘defects’ are actually de-commissioned functionality.
Manager: We need to know what’s being changed in the application, we can’t be chasing down defects because of changes we don’t know about.
Me: Agreed. We’ve extended the offer for you to come to our end of iteration demos and until this week we haven’t made any changes in existing code so I agree, with these changes we’ll have to invalidate some of the old regression tests that aren’t needed anymore.
Manager: I don’t have time for that. Is there some type of documentation about the changes?
Me: Yes. We’ve started using javadocs to document the code and our functional information is in Rally. Brief, but explains the functionality well enough. The team members would easily be able to figure out the impact of the changes since they all know the app well enough.
Manager: I can’t ask my team to waste time sorting through Rally to find this information.
Me: We can export a list for you and email it, it’s a 4 or 5 column XLS with a good summary.
Manager: Do you know how much email we get? I can’t agree to that.
Me: Ok, how about you and the members of the other groups who need insight into the changes come to our demos? We do a 15-minute quick overview before digging deep into the stories we completed.
Manager: They can’t do that, we don’t have approval from their managers to go to your demo.
Me: Ok, we do send a summary of what’s being updated when we make our iteration commitment and we send a summary output after the iteration demo, I can include you on those.
Manager: There’s too much to do, I have to worry about this project, that release, aligning this team with that team, I get too much email now, we need a process.
Me: Ok, so how about we just have the people from the other groups attend our demo, we’ll give them the 15-minute overview and send the summary of changes before and after the iteration. If we need to do a more in-depth session, we’re happy to.
Manager: I’ll go talk to the managers to get permission for the other resources to go to the demo.
Me: Great, that should make it easier and really efficient to share information between our Scrum team and the waterfall and regression teams. Thanks!
At the end of the conversation we were right back to where we started. A quick and efficient session to share knowledge with the people who are programming or testing the software. I had continued this conversation with a few folks to get to the real problem and the challenges being faces are typical.
So what’s up with all the excuses? Did we have to fill up the 30 minute time-slot for the meeting to be effective? I decided to dig deeper:
Q1) Why was the initial response that people couldn’t spare 15 minutes every 2 weeks to get visibility?
A1) Because we are too busy.
Q2) Why are we too too busy?
A2) Because regression testing takes 3 weeks.
Q3) Why does regression testing take 3 weeks?
A3) Because our testing is manual.
Q4) Why is our testing manual?
A4) Because that’s how we do it.
Q5) Why do we choose to do it that way?
A5) Because there are too many projects and we don’t have time to do it another way
I’m sure there were a couple more excuses tossed into that first conversation, I started losing count but the underlying problem of having too many projects in progress at a time are causing a whole host of downstream problems.
At this stage, portfolio management isn’t something we can focus on, especially in a large and complex organization. First step is to create visibility to outside teams and trim down the regression suite so there is less waste with manual testing. Our team has already started looking at automating end-to-end regression for happy path scenarios which will also reduce the amount of time spent on manual testing.
It’s a small step, but we need to start somewhere but the message in this post is that things aren’t always as they seem. The initial response is often a gut-reaction based on stress or other factors and it shouldn’t be confused with resistance to improvement or efficiency gain.
One of the simulations I like to facilitate during training sessions is a simple penny flipping exercise learned from Mishkin Berteig to show how the team approach can lead to substantial improvement and productivity gains.
The idea is simple, have the attendees work in a serial process where they have to pass the penny from person to person. The goal is to get the pennies facing heads up in ‘the product environment’ (which is a piece of paper) at the end of the chain. The second part has the same goal, but the teams can accomplish it however they want. I usually repeat the second part a couple of times to prove the meaning behind the exercise. I’ll add a post with the mechanics on this game later.
Anyway, last night my 2 kids and I were playing dominos which always results in a living room disaster since we have a few hundred of the them. 20 minutes for me to set them up, 10 seconds for them to knock them down. When it was time to clean up I simply stated the goal. ”Ok guys, time to put all the dominos away in the clear bin“. Just like a high-performing Scrum team, we started singing the Wonder Pets Teamwork song (what’s gunna work? TEAMWORK!) and each “team member” started cleaning up.
My 4 year old son started picking up the dominos nearest to him, same for me and my 3 year old daughter. The bucket was pretty much centralized between the 3 of us. After we had cleaned up the dominos closet to us, my son immediately took the bin, moved it to the next ‘batch of mess’ and we proceeded to start with whatever dominos were nearest to us. My daughter had walked towards the pile my son started with so she quickly self-adjusted and started on another pile.
I was stunned. The collaboration was completely instinctive and there was very little, if any, discussion. We all knew what the goal was and we all chipped in. Once there were only a handful of dominos left, all 3 of us focused on that so no one was idle until there were less than 3 dominos left.
Sounds silly, I know, but the Agile principles were were much apparent to me during this clean-up session:
- all team members understood the goal
- team members self-organized
- team members adjusted based on work remaining
- team members started with highest priority items (as in, we all started with the pile in front of us)
- we had fun while working! (For those who don’t have kids, trying to convince a 3 and 4 year old to clean-up is not really that easy most of the time!)
I often get complaints in training sessions about the simplicity of the exercise and that moving pennies is different than real-world work. I agree, it is but applying the one-team, shared goal value is more important. Once folks buy into the team system, the rest of the work falls into line much easier.
This is a quick and simple exercise I ended up doing ‘off the cuff’ but based on feedback from the class, had huge value that talked about why the conversation is the most important piece of the user story.
I focus heavily on making the point that the written word is less important and while INVEST shows us there are good ways and bad ways to write stories, the disconnect is always a result of lack of communication.
This exercise takes Mike Cohn’s “entree comes with soup or salad and bread” statement from his User Stories book and allows small groups to write down what they are giving me when I order that in a restaurant.
- whiteboard or flip chart to record the responses
- a few sticky notes or paper for the small teams to write on
- play-food could be optional to make it more fun!
Set the Stage:
Have the group split into small groups of 3, depending on class size. I had 3 groups of 4 in this particular class. As product owner, I want to order the entree with soup or salad and bread but I have to run to another meeting, I expect to get what I ordered by the time I get back. You can leave the room, but I stayed in the room to hear the type of conversation that is happening.
Timebox: 5 minutes (up to you I suppose, I figured that was reasonable)
- ideally you will get at least 2 different orders. In this case, each group gave me 3 different orders which was perfect to demonstrate the value behind the exercise
- immediately I heard conversations like “what did he mean? does he want soup or (salad and bread) or (soup or salad) and bread?”
- didn’t hear conversations like “we can’t do this until we can ask him what he wants to clarify” – all 3 groups just decided to guess and hope for the best
- the conversation is the most important part of the user stories’ 3 C’s.
- focus on the conversation, not the text in the story
- the conversation to clear this scenario up is 1 minute or less as opposed to the effort required to revamp the documentation, then update the story in your tool
- business people and developers MUST communicate daily
I just thought about this as the class was starting so there was zero prep or thinking, just figured it was better than me blabbing on and on about why people should talk to each other! I plan to try this exercise again, the feedback from the group was unanimous. They all ‘got it’ that the point of the user story was the conversation. I start each class with a focus question and this exercise quickly answered about half of the responses. Most were concerned about the story missing details, how can I write better stories for the team etc.
Would love to hear your thoughts!
Agile Coach Camp 2010 is coming the weekend of March 19, 2010 in North Carolina. I’ve heard great things about Coach Camp and this is my first opportunity to attend. You can check out their site here and for those who aren’t familiar with Coach Camp, it’s an Open Space conference focused on peer-to-peer learning and exploration as opposed to the traditional speaker/audience conferences I’m not a huge fan of.
Anywho, onto the position paper: You’ll notice these are high-level points, that’s the point of Coach Camp. The goal is to share experience and gain feedback from the Agile community.
Title: A Recipe for Enterprise Agile Transformation
Background and Challenges:
- large department within large organization
- tall hierarchy, great deal of office politics
- heavily silo’d organization
- complex product portfolio
- mix of full time, contractors, outsourced developers and teams
- limited people with Agile experience in the organization
- no recognized Agile champion
Speaking and Presentation topics I plan to share:
- transitioning focus of functional managers and other roles
- there is much confusion about ‘where does my role fit’?
- breaking down silos between multiple groups
- having to prove you are worthy of being trusted
- demonstrating and sharing success and failures
- portfolio and team organization
- how to structure your teams with the right skills for the project
- techniques for handling ’specialist’ groups
- how these groups interface with teams
- how these groups share information gained from working with multiple teams
- cross-project knowledge sharing (technical or process related)
- getting people together to talk about experiences.
- How PMO and process teams evolve
- more teaching and coach, less command and control
- spreading Agile culture
- making it about the organization, not the coaches
- teaching the organization to think for themselves
The above topics will be accompanied by some fancy diagrams I’m working on for an experience paper and due to the format of Coach Camp, if my paper is accepted and put into the plan, the topics discussed with likely be determined by what my peers want to hear about.
I am still planning on writing and experience paper I had hoped to have finished by now where I can share more details. Interested in your thoughts and experiences!
Ah, good old re-work. The thorn in the side of Scrum teams, the impossible mountain to climb for development teams. Re-work is un-avoidable. When people see working software, they get new ideas and might want some changes. Here are some thoughts for handling re-work based on a few scenarios that popped up at work this week.If We Knew Earlier, We Coulda Did Something About it
Situation: During our iteration demos the team I’m working with found that they had improvements and suggestions now that they could ’step back’ and see their work. Other folks who we invite to the demo would have some small ideas or our Product Owner would have some suggestions that were nit-picky, but nonetheless would be better for the user.
Problem: Waiting too long to get feedback.
Solution: I’m happy the team came to this conclusion themselves in the retrospective. One of the team members posed the question that why don’t we show our product owner immediately when we complete the story and not wait for the demo? Side note: I’ve mentioned this to them a few times, but it was great to see them take a problem and apply the learnings on their own.Splitting the Iteration into Work and Re-work Phases
Scenario: There is too much re-work at the end of the iteration so we are going to take our 1 week iterations and shorten them to 3 days so we have 2 days to do re-work.
Problem: too much WIP and lack of communication between team and product owner. (In this scenario the product owner isn’t available full-time to the team and the proxy he assigned can’t always make a decision). There are a few other things happening here as well. The work this team does is non-software and they rely frequently on interacting with people in other departments. They’ll start something, get blocked and move on to something else therefore creating a great deal of waste.
Solution: The team has been struggling with this for a few iterations, I’m not working with them but did have a chat with their Scrum Master since he felt it was a failure on his part. Not so at all. I told him maybe trying to hammer Scrum into their work-style wasn’t the best thing to do. Perhaps a Kanban system would be more effective for them. We talked about what that meant and they’re not ready for that so instead they’ll try communicating with the product owner more often and help the PO understand he needs to be available for the team to fulfill their commitments.Agile/Waterfall Hybrids is What we Did!
This one came up in a training session I was doing. One of the attendees said mixing waterfall and Agile can work because in his experience there was no way to handle re-work in Agile. The solution to this is similar to the first scenario I discussed at the start of this post.
The root of this problem is not getting feedback early enough or the lack of daily communication between the Product Owner and the Team that is required when using an Agile process. A deeper problem was the apparent separation between programmers and testers on the team he was talking about. I wasn’t able to deep-dive into the scenario since it was in the middle of class but I offered some suggestions about why it might be happening.
All of these examples, in my opinion, are some of the main reasons why companies fail with Agile. They interpret “Agile” to mean flexible and let’s just change the rules to make it work for us. While Scrum is a simple, adaptable framework, the fundamentals shouldn’t be changed to accommodate a broken process. This type of dysfunction can lead to mis-trust between the Team and the business and also cause a rift between programmers and testers as they will start to ‘fall back’ into a waterfall mentality.
It’s important that the Scrum Master or Coach help the teams struggling with this to understand what the real underlying issue is and to work through it.
The Agile Manifesto is the heart of soul of what it means to be Agile and I often refer back to when talking to colleagues and especially with those that are new to Agile. This post was sparked after a great cross-group meeting that happened yesterday where some information was shared between groups that typically wouldn’t have otherwise collaborated.
I had been asked to present a quick talk on Scrum for a couple of new teams that will be starting up soon, followed by a quick overview of these new projects. The output of this session coupled with what I learned at AYE and through the weekly coach round-table I attend with Michael Sahota, Gerry Kirk and Declan Whelan (special thanks to Michael Spayd for his recent ‘guest appearance’!) gave me some inspiration to write this. I hope it is of value to you.
Client Success over Personal Gain: The Coach isn’t the hero. They are there to help the organization. They need to understand the client and contribute to their success, without worry about accolades or personal gain. This includes the coach fulfilling his duties to the best of his abilities instead of holding back to extend the gig. I like to take the approach that my goal is to work myself out of a job as efficiently as possible because the organization needs to be self-sustaining to succeed. Others will argue that “well, I need to make a living” but I knew the risks when I took this path. If I’m any good I’ll find more work.
Guiding over Dictating: Resist the temptation for the ‘my way or the highway’ approach, especially in organizations that have a more controlling culture. Organizations need to learn and they learn the same way a team learns, through experimentation. A coach needs to help guide them to the answer because the people in the organization are best served to find these answers with the help of a coach.
Objectivity over Subjectivity: The coach needs to remain agnostic in order to avoid making emotional decisions. I do get frustrated when my observation is that the client isn’t listening but that just means I’m doing a poor job of communicating. Remain clearly focused and you will serve the client better.
Adaptation over Doing-What-Worked-Last-Time: Ok, so this one is the same as ‘Responding to Change over Following the Plan” however I mean that organizations are unique. What you were successful with at your last gig won’t necessarily translate into success at your current gig. To me, this one is about understanding the organization’s culture so you can frame your approach. Controlling cultures will require a different approach as opposed to collaborative cultures for example.
I firmly believe it’s the responsibility of any coach to make sure the Agile transition is about the client. Deflect focus from being the expert and help the organization understand that Agile is a tool and it’s only as good as how it’s used by the people using it.