Ok, now it’s time to finish the story. To those that visited and read the first part of this article, thank you. I’ve been surprised and also very happy at the visits this site has had.
Sit down, strap in, hang on, the road to Agile can be a bumpy one. Here we go………
“And it’s whispered that soon, if we all call the tune,
Then the piper will lead us to reason.”
It is really important for teams to remember that a user story is a reminder to have a conversation about the value to be delivered. I’ve found that quite often stories simply become too big, too much information. It becomes a planning up front exercise and almost obliterates the importance of conversation. I like the idea that “if you can’t fit the detail on a card, get a smaller card”, the spirit of this idea is spot on. I’ve also seen that user stories get created large and stay that way. The notion of breaking user stories in to small slices of value is not an easy one to get your head around when you have just come in from the “waterfall winter” into the “agile spring”. The team I am currently working in was doing this when I joined them. Large user stories with many, many tasks (so, so, so many…..by the way tracking these suckers is time consuming and delivers no value to the client). The story points were allocated at the task level. The points were recognised when a task passed to done even though the task might not have delivered any client value. I see this as a relative of waterfall. We now work on small stories and keep task cards to the bare minimum. We recognise story points only when the user story crosses in to Done. We build user stories using the INVEST heuristic. Everyone has a laminated copy of this on their desk, there is a large A3 poster of it in our work area and also in the meeting room we generally use when producing user stories.
Another issue I have noticed is that acceptance criteria, for whatever reason, are often not defined, not seen as important. I’ve spent considerable time on the development floor talking to people about why acceptance criteria are important. My current team now has Definition of Ready requirement – user acceptance criteria defined. I didn’t champion that change, one of my team mates did (happiness – someone was listening).
Sprint planning can be a tricky beast. People start keen, feel familiar with the process quite quickly and start to “auto-pilot” their way through the session. Keep sessions short but punctuate the session with breaks every 50 minutes. People will focus better if they know it is not a continuous 3 hour session. I really favor keeping people on their toes in these meetings. I ask people for opinions on cards when they may not be expecting to be involved. It’s a really important period for people to be thinking about what is coming up for them to work on. Do we have unknowns, uncertainties, let’s capture them. If you know something the rest of the team doesn’t, reveal it so everyone is aware. The power of “group think” is important in this meeting. Think about the size of the story, is it testable? If it is a technical card keep the developers honest. I’ve seen plenty of attempts to gold plate a solution why beyond the value proposition required for the project. Be alert and challenge when you think it is required.
When I first started in an agile team we estimated using story points, relative sizing. Management could not get their head around this. To be fair, that’s not surprising, they spent little time trying to understand it (not that it takes a lot of effort, it’s no Mensa puzzle). After a period of time they discovered that each of our scrum teams had a different idea of what 1, 3, 5 user points looked like. Kinda blew their minds, their response kinda blew ours. Mathematics is a magical thing, you can do things when you manipulate numbers. In this instance a whiz kid with a spreadsheet figured out that a user story point represented half a days work (did you know every time you equate a non standard item such as a story point to a defined value such as half a day, an agile fairy loses its wings – makes me sad). So from then on people swapped story points with days as if they were the same thing (wait a minute, small correction, a story point is bigger as one of those represents only half a day of effort). Can I just say, and this is just my humble opinion, choose days if you want, choose story points (relative sizing) if you want but DO NOT use both as if they are an interchangeable currency. If I may borrow from AC/DC, it is the “highway to hell”.
Stand by folks, a bit of controversy, I HATE stretch goals. There you go, I said it, I’m an agile heretic, or am I? I’m quite binary on this. If the story is of value and can fit in the sprint, it goes into the sprint backlog. If it can’t fit in the sprint backlog, move something of lower value out. If there is nothing of lower value leave it in the backlog. If, and only if, we start getting through stories faster than planned, then bring the story in. The minute you create stretch goals people want to meet that goal. They start working a little faster maybe, they cut a corner maybe, all for the thrill of getting that elusive stretch target and gaining “awesome” status. How about we just focus on producing sustainable quality, seems like a better target to me.
I’m also a little wary on team velocity, don’t just accept it, understand how or why it is a particular value. I worked in a team where one team member in particular did a stack of out of hours work (he just loved the project with a passion). This is great but it artificially blew our velocity through the roof and management jumped on what that could mean. It is also not a sustainable practice. The team had to request less of this “passion” work so we could ensure sustainability. As counter intuitive as that sounds we had someone sprinting when we needed him to be good for a marathon. Use it but don’t abuse it. When the intense bursts are required be ready for it, otherwise aim for a steady pace that delivers value to clients.
“And a new day will dawn for those who stand long,
And the forests will echo with laughter.”
This is the bit about scrum that does my head in. Not because it is hard to understand the value, not because it is hard to understand why it is a prescribed ceremony, not because we do it but because the delivery of value seems to be exceedingly difficult. I actually do not know where to start. OK how about people showing up unprepared to take part or not caring because “other people will put stuff up that I would have put up” (and yes this was actually said). In part 1 of this article I mentioned not everybody is up for the change (people love change they just don’t like changing), I think you see it manifest here. The team ethos, it’s agility (or lack of both), gets laid open in this meeting, cost for no value. make a habit of noting things (good, bad, otherwise) as they happen so you don’t forget. But don’t wait for retro to discuss something that should be discussed now. Instead discuss it now and report the outcome in the “good” column.
So let’s say we have a good retro session, we identify some actions for follow up. Where to from here? My experience is that they (maybe) get put on an action board, no specific champions and at the next meeting get explained away as having been actioned or no longer relevant. Awesome, all inspecting, no adapting (was that another agile fairy plummeting that I just heard?). Let’s ramp this up a notch. We identify actions that will improve the team, we create story cards, we add them to the sprint, we’re gonna do stuff, umm no we’re not. Why because the Product Owner seems to have power to force other stories in to the sprint backlog as higher priority. Raise this to management, who want to see improvement in the teams. Response, not word for word here, but in summary “improve on your own time” (that was an agile fairy expiring, I’m sure I heard a faint scream). Improving on company time costs money. The ability for it to build better teams and all the good things that come with that are somehow less important.
To round out this part of the discussion, there is, apparently, only one way to run a retrospective. I was quite surprised by this, still am. It seems that when a company is contracted in to help you transform to agile the retrospective format they show you IS the definitively best way to run one. Now I’m not overly clever but you do get the odd thought that there might be more than one way to skin this cat. As ground breaking as this may seem, when you look on the web, grab a testing magazine, read a book or two it turns out that there are a lot of ways of running retrospectives and, this blew my mind, it doesn’t have to be run by the Scrummaster (note: my sarcasm meter topped out on that last remark, for health reasons I’ll refrain from further sarcasm for a little while). Can I just suggest the occasional change up, doing something a bit different, something that might be really relevant in the context of the sprint, is a good thing.
Quality and Value
“If there’s a bustle in your hedgerow, don’t be alarmed now,
It’s just a spring clean for the May queen.
Yes, there are two paths you can go by, but in the long run
There’s still time to change the road you’re on.”
“There’s still time to change the road you’re on”, were Led Zepplin singing about agile, scrum and client showcases? Although a bustle in your hedgerow is probably not the trigger for a showcase (can anyone that knows what that line means drop me a message – sorry off task but I really need an explanation). So lets talk about definition of done (DoD) and showcases.
What can I say about DoD? I guess the first thing is make sure the team has one. It’s probably assumed this will happen. You might assume the tester/QA analyst on the team would drive this. You might assume that the team being so focused on sustainable quality would put this high on their list of things to do. Don’t make that assumption, it doesn’t hold. A recent comment from a colleague was quite interesting, “it’s just a checklist”. OK, can’t argue with that. Maybe think about what that list represents. Every time an airline pilot takes a flight it is checklists from gate to gate. Doesn’t matter how many hours flown, those checklists must be run. It’s not a lack of professionalism driving this, in fact it is the opposite. Professionalism drives the airlines to ensure the delivery of consistent quality, checklists help this. I’m not a nervous flyer, I love flying but I do like the idea that the guys up the front are going through checklist that, for example, makes sure those wheels are down and locked when we land. DoD, in my mind, represents the same thought process. What do we need to do to ensure each story is delivered in a state that delivers the highest value? Right, let’s capture those things and check them off as we go. Let’s use consistent inspection to make sure we are checking for the right things. Also be aware of teams that apply DoD at the very end to check if the card should be allowed to cross to done. Get them in the habit of applying DoD across all phases of the story so the step across to Done is an easy one. Get your DoD right, apply it rigorously and consistently and you have a pretty solid piece of your governance layer in your control.
In the team I’m currently working with we have out DoD printed large size on A3 and up on a wall for all to see. I have laminated A4 size copies sitting on all team members desks. As we think of things to add or remove from our DoD sticky notes get added to the A3 copy. These then get discussed by the team, the DoD gets redrafted a required and new copies re-issued. Seems to work really well.
Showcases fascinate me. The idea is a really strong one, I’m seeing too many people treat it as an optional item rather than a ceremony with real power. Show your stakeholders what you have built during the sprint, get feedback, use this to plan the next sprint, make changes to the product backlog, etc, etc. What happens if your client isn’t really interested in attending (remember the company decided to go Agile and use scrum, the clients didn’t request this change)? What happens if you are running 2 week sprints but your company has decided to hold internal showcases every 4 weeks? The internal showcases are great for getting the development floor together and demonstrating product changes but for generating meaningful feedback, useless. My answer to this is to run showcases, just for the team, at the end of every sprint. Why? My thinking is that across a sprint you look at bits of software, you focus on the stories you are involved with. You have knowledge of what the sprint is achieving but you don’t see the bits at a more holistic level. Neither does the Product Owner. This gives the team a chance to look at changes from a different level, perhaps ask new questions about what is being done, bring new insights about possible new value or changes that would add greater flexibility, better user experience, new conversations we should have with the client. Use this session to drive thinking around what the highest values in the product backlog are. Have our views on this changed now we have seen the software operating beyond the individual story level?
Testers – Who Are They?
“And as we wind on down the road
Our shadows taller than our soul.
There walks a lady we all know
Who shines white light and wants to show
How everything still turns to gold.”
Easy answer right? These are the people that harass the developers and tell the story writers they are using ambiguous language and writing stories that cannot be tested. They shout joyously when finding a bug and……… stop right there. If you are nodding your head in agreement either shame on you, or, you have my sympathies because you have some significant dysfunction in your team.
When I first ventured in to scrum I had a big question that I could not get answered. Every time I ask it the agile consultancy would go deaf, pretend not to hear the question. The question – what is agile testing? I decided I could probably find out the answer myself. Turns out there is no agile testing, just testing in agile. Bring your test skills from waterfall, just be prepared to use them in different places and don’t hold back testing to the end of the story, test from inception to Done. Be willing to learn new and apply new test skills. Your ISTQB Foundation Tester is not the be all and end all. Get busy get learning. If you don’t understand the basics of exploratory testing, get cracking and start learning it. Even more importantly start applying it. Get comfortable with the idea of minimising test scripts while still meeting your obligations within the context of the engagement. Learn to understand the context of the engagement so you don’t use inappropriate test techniques (yes this is not an agile specific thing but doing the same thing over and over without thinking about its relevance to the context, drives me crazy. Good and great testers do not do this). Regardless of how you document your testing to be executed keep it to the last possible responsible moment, maximise the power of change without needlessly increasing waste. Think about whether a bug needs to be logged. Can it be resolved without being logged? Can we do this and ensure that the problem is fixed and not forgotten? If yes then get the team together and make sure the team agrees a procedure to achieve this. There might be times when you do need to log a bug. Recognise when this is and make sure the bug gets logged. Perhaps your context demands that every bug get logged, in such cases, ignore my previous bit on minimising bug logging.
“And if you listen very hard
The tune will come to you at last.
When all are one and one is all
To be a rock and not to roll.”
Everyone on a scrum team is a tester. Sure it might not be their specialty but everyone can test. Some might need more guidance than others, it might take the “non specialist testers” longer to complete the testing but they can test and they can test well. I’m lucky I work in a team where everyone makes themselves available to help with testing when it starts to get a bit busy in the test arena. Not all teams do this (I mentioned silos within a team earlier). I wont accept testing being completed at a lower standard but I will accept that more coaching and teaching my be required. It might mean I need to work a little longer some days to support my own work and get others to understand basic requirements. What I get in return though are team mates that are getting more engaged in ownership of value delivery and they are upskilling. They are not going to become incredibly skilled testers any time soon but they will be useful testers soon enough. That is a massive win for the team and moves us another step closer to improved sustainable quality at higher sustainable efficiency levels. Do not underestimate the motivational effects cross training has within a team. It is a real team builder.
“And she’s buying a stairway to heaven.”