I recently attended a very interesting 2-day Scrum Master course with Dan Rawthorne, a seasoned agile practitioner, and that made me realize that Scrum is a living thing and has evolved from what I thought I had figured out, and is still evolving… Dan has a lot of experience managing agile projects and is one of the people shaping Scrum day after day. He has a book in preparation which I’m eager to get my hands on.
So, what I was familiar with and had put in practice was what Dan called “Grandpa’s Scrum”, which is actually the original version of Scrum. Nothing wrong with that, but Scrum has been refined since and a few subtle but important changes have made their way into Scrum.
Also, the course made me understand some of the misconceptions I had about Scrum.
So, here are, in no particular order, some points that were mentioned and that I found noteworthy:
- The sprint backlog is not untouchable! Just because you agreed during sprint planning on what you were going to try to achieve in this sprint, doesn’t mean it can’t change during the sprint… Reality might knock in and force you to change the priorities. What if the server room is on fire? Are you still going to try to stick to the initial plan? Of course not. In any case, the Product Owner is the only one who is allowed to change the priorities, and he can do so at any time, even during a sprint!
- The “product backlog” is actually called simply the “backlog”, because it does not only contain items about the product, but anything that needs to be done! Similarly, “user stories” are now only “stories”, because they’re not necessarily about the product directly. You might also find them referred to as PBIs (product backlog items). While these terminology changes might seem minor, I think they are necessary because they influence our understanding of Scrum.
- Stories need to have a “definition of done”, that is a list of conditions that the team agrees will mean the story is, well, done. This might seem obvious or implicit but it is not, because this definition might include some points that are not directly related to the implementation of the story but are crucial nonetheless, such as making sure it’s tested, making sure the code is committed, making sure the code has been reviewed, etc.
- The Product owner is an integral part of the team! Which means he can’t be on te business side; that would be the Business Owner. The Product Owner is responsible for communicating with the Business Owner, translating his wishes into stories, and prioritizing them. In return the PO is the single person accountable to the BO for how the product is evolving.
- Estimating stories is (at best) useless, unless you want to fall back in the old waterfall / plan everything ahead model. What matters is: do you want to implement it, or not? Only tasks that derive from stories can be estimated, for the sake of knowing if they will fit in a sprint or not. Stories need only be prioritized.
- “Backlog grooming”: that’s the action of cleaning up, refining and re-prioritizing the backlog. Of course it’s something everyone does, but it feels good to have a name for it
- Burndown charts are avoidable: since the beginning I found them unnatural; what, a chart going down?? Plus burndown charts actually measure activity, not progress. What do you want to know, how busy the team is, or how fast is the project moving? I assume the latter, then the only thing you’re interested in is how fast stories are solved, period.
- Subject Matter Experts (SMEs) can also be technical experts (architects, DBAs, …), they’re not necessarily experts in the application domain.
Finally, a note on the Scrum Master role, which this training was mostly bout. This is always the most challenging role to explain to a non-Scrum person, because it has so many aspects, and can’t be appropriately summarized other than saying he’s a “facilitator”… An interesting (and quite sexist, but let’s keep that aside) analogy is that of the family: if you consider the team as a family, then Scrum Master would be the mom: taking care of everyday tasks so that the house is well-run, the children (other team members) are well behaved and play nice with each other, etc. In this analogy the Product Owner would be the dad, maybe away working for part of the day (actually, talking to the Business Owner, stakeholders and SMEs…) but having the last word on what needs to be done and when.
In any case, if you can attend one of Dan’s conferences or training classes, this will be time well spent.
Story: Scrum Master Certification course. Done. Next…
I have updated my scrum Excel helper workbook:
- added “category” to user stories, changed “priority” to “value”
- added “sprint focus” header to sprint sheet
- added velocity
- remaining units now extrapolated from previous day if no data entered
- a few cosmetic changes
Here is the updated version:
I’ve known about DSLs for a while, but a very interesting presentation by Neal Ford at the TSSJS in Prague last year made me reconsider the subject. Before, I considered DSLs were applicable only in very specific situations, like where there existed a huge number of requirements that were expressed very formally. Think rocket launching for example.
But now I tend to think that in most situations, there exist requirements or business rules that could be captured more easily than by writing sentences in a requirements document, then writing more detailed sentences in a specifications document, then writing test cases to make sure the requirements are fulfilled, then implementing the logic in code. And then of course doing it all over again when the business rules change.
If we could express these business rules in a way that could either be interpreted at run-time, or be compiled into the software, we could skip all the chain. We wouldn’t need to validate the software’s behaviour (regarding these requirements) against specifically written test cases, because the integration mechanism of those business rules would have been validated. In other words, if the software doesn’t behave as expected, it’s not because of a bad implementation, it’s because of a bad business rule.
I once worked with a company named ItemField (which is now part of Informatica) that had a technology (ContentMaster) to transform almost any kind of document (mostly Office documents, PDF and such) into XML, and vice versa. They had thought of extraordinary ways to use their technology; for example, by building an appropriate transformer, they could turn a formal specifications document into a parser for the format described by the spec. If that sounds esoteric, consider the specifications for SWIFT messages, also known as ISO-15022: it’s a huge collection of rules that define different kinds of messages, and how they can be constructed. Now imagine having to write a parser for all the message types… it would be a nightmare to code by hand and test because there are so many rules to implement! (Some have tried: see project WIFE – still a work in progress). Well, ItemField had written a transformation that generated XML parsers and serializers for SWIFT messages right from the specification! So if anything changed in the spec, they just had to run their transformation on the new spec, and that would generate new parsers and serializers. They called it specification-driven transformation.
Apparently ContentMaster was included into Informatica’s portfolio as part of their B2B Data Exchange product family, but I don’t know what survived of the specification-driven transformation.
Anyway, the idea behind this approach is dazzingly powerful: use business rules exactly as they are formalized . Don’t rewrite them N times using a different formalism, creating N possibilities for things to be misinterpreted by a human. For example, we know many domain specialists would write rules in Excel; given a technology such as ItemField’s, it is usually possible to parse these rules directly from the Excel sheet (provided they are reasonably consistently written), and generate whatever is necessary to incorporate them into the software. If rules change, the domain specialists update the Excel sheet, we run the transformation again, and that’s it. Once we are confident that the transformation works (and this means that it has been thoroughly tested!), we know that anything wrong with the business rules comes from the rules themselves, not from the code.
I think this is where we’re heading, generally speaking: giving more control to non-IT people over software, by shortening the way between their expectations and the software they use. MDD is part of this trend, because models are more likely to be understood and driven by users than programming concepts. If we take abstract models as a kind of formal specifications (which they are), then what applies to Excel sheets could also apply here, provided that we can automate and shorten the path from model to final software. This is not the easy part, I admit.
Agile methods of course are also part of this trend, in a different way, because they involve stakeholders very closely and often in the process, and also aim at shortening the path from specifcation to software. For example, in Scrum the product backlog plays the role of master requirements, and while it still has to be written by hand, it is the only artefact between users and the development team.
I think we’ll see this trend amplify over the next years. It might feel like this will ultimatley mean less work for IT people, I don’t believe it. But that might just be wishful thinking.
Remember the Agile Manifesto? “Individuals and interactions above processes and tools”…
I was looking for Scrum tools, so I experimented a few of them and I thought all of them were overkill and tried to make you do Scrum the way they wanted. So I thought about the Agile Manifesto and wondered, what’s the simplest tool you could use to manage the Scrum artefacts? Besides pen and paper of course.
This is how I stumbled on Nicolas Martignole’s Excel template for Scrum on his blog Le Touilleur Express. And the truth is, you don’t need much more than an Excel workbook to manage your product backlog and track your sprints progress…
Nicolas’ template is fine but it has a few things I didn’t like, so I made my own. In particular:
- I made each Sprint worksheet standalone, and not depend on a System worksheet. So now all you have to do to initiate a new Sprint is to copy an existing Sprint worksheet and fill in the task list.
- I fixed the formula for computing theoretical remaining scrum units.
- I added conditional formatting to display the actual remaining units in green or red depending on whether the team is ahead or lagging.
- I tried to be more consistent in the use of colors, fonts and formatting.
Here it is, you can do pretty much what you like with it (it’s licenced under Creative Commons). If you have any comments I’d like to hear them.
Scrum Excel Helper Workbook