Here are my thoughts on some of the recent doubts I’ve had as someone who is usually a change agent and agile evangelist in some capacity or other.
These are questions you can ask yourself as an agile coach, as a sociotechnical delivery consultant, as an architect, as a developer, as a development manager, as an HR manager, and really as any person who plays a part in an organization’s efforts to deliver on its mission statement.
In every organization and in every team, I run into one or two customs that people tell me are part of "Scrum by the book", that aren’t actually in the book.
I’m a developer and I like Scrum. Not every developer does. A complaint I sometimes hear is the following:
We spend so much time in meetings that I don’t get around to writing code!
If you have - or are confronted with - such a complaint, I have some tips for you to take into consideration
The book The Fifth Discipline by Peter M. Senge landed on my doormat recently. I ordered it after hearing Andrew Harmel-Law of ThoughtWorks mention it at the JFokus 2020 conference (article in Dutch). His takeaway was as follows:
"Placed in the same system, people tend to produce the same results".
Once I received the book however, a line at the top of the cover caught my eye:
"In the long run, the only sustainable source of competitive edge is your organization’s ability to learn faster than its competitors"
This statement rings so many bells I’d like to dwell on just that without even going into the book itself. There are two obvious yet often missed clues here that I’d like to share.
The times I’ve worked on a project where the scope is "rebuild the existing implementation, but with new tool / techonology X", I’ve encountered various pitfalls that make these projects much harder than they need to be.
Let me offer some tips on how to deal with them.
When you start work on a product, your velocity may be low and not reflect the investment you need to make to have proper continuous delivery. Here’s an idea to make it visible.
When you build a soda factory, producing your first can of soda effectively costs as much as the entire factory. Of course you plan to produce a whole lot more, and distribute the cost over your planned production.
This is an analogy that’s worth considering when starting on a new product with your Scrum team. During the first few sprints of work on a product, a team is often busy setting up the delivery pipeline, test framework, local development environment, etc. All this work undeniably has value, but usually isn’t expressed as "product features".
For example: You have 20 similar functional user stories that would be an equal effort to implement. The first 2 sprints your functional burndown is low. This is because during sprint planning, whichever user story gets picked up first has the questionable honour of having subtasks such as "Arrange access to Browserstack", "Set up Jenkins", "Set up AWS account", "Set up OpsGenie for alerting" and "Set up Blazemeter for load test", to name a few.
Consider what the Scrum Guide says about a deliverable increment:
Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available.
a "Done", useable, and potentially releasable product Increment is created
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.
This is problematic because it means your first few sprints tell you little about your ability to deliver value given the manpower and knowledge at your disposal. Also, it may mean your first few sprints fail to deliver any functional increment that could go live. Because what you’ve decided constitutes value is different than what you’re investing in, it may feel like you’re forced to do necessary work without seeing measurable results. You have little to demo during your sprint reviews. Product owners get nervous the longer this takes. You’re destined to be off to a poor start.
See the following sprint backlog and resulting velocity chart. When you hide all the automation and measurement boilerplate work as subtasks underneath whichever user stories you pick up forst, your burndown charts give the impression you achieved very little.
This doesn’t seem fair.
Some resort to starting out with a "Sprint 0" of undefined length and without a sprint goal, to just get all the ramping up out of the way, as though it’s a necessary evil. Don’t do this. Focus on delivering value from the start.
The Scrum guide by scrum.org doesn’t mention spikes, but it has something else: the Product Backlog Refinement. And this often gets mistaken for a Scrum Event that puts the entire Development Team in a room with the Product Owner for half a day a week. The entire team then looks at the top of the product backlog and tries to uncover all the details there. They do this until enough uncertainties are uncovered and the team feels confident it can estimate. It gets worse when there is a project manager on board who needs estimations to discuss budgets and delivery dates before deciding whether he wants a story at all. This way, you end up spending a lot of time on value you’re not delivering. At some point, somebody will say: This is taking too long; let’s make it a spike and move on. And that’s not what spikes are for.
A spike is a concept from Extreme Programming (XP) where the team does a technical examination of possible solutions before committing to one to solve a requirement. Like many concepts from XP (for example: Daily Standup vs Daily Scrum), it’s found its way into many Scrum projects. The Scrum Alliance adopts and expands the concept by saying it is a story-like backlog item that yields information rather than a working increment of software. This information can be both technical or functional and is deemed necessary before deciding on whether or not to implement a functional story. And if so, it ensures that enough information is available to know how. The Scrum Alliance warns that a spike should be used sparingly, if at all.
After the success of agile transformations that gave organisations the ability to respond to a change in the market more quickly and frequently, the last decade saw DevOps emerge as another magic wand. While valuable by itself, DevOps should actually be treated as one of many aspects of the Shift Left paradigm applied to the full software delivery life cycle. Patrick Debois, Andrew Shafer, John Allspaw and Paul Hammond coined the word DevOps around 2008. It comes down to the insight that combining the disciplines of development and IT operations by removing the thresholds between them allows for the elimination of waste and improvement of quality and speed of software delivery. The concept of Shift Left comes from the field of testing and boils down to the idea that the earlier in the software life cycle a fault is found, the cheaper it is to fix it. The accompanying model for this concept is that the process for delivering software goes from left to right as it goes from concept to cash.
Today I visited the UXDX Conf in Amsterdam.
UXDX conf is based around the UXDX model which integrates UX into the Development loop by breaking down the barriers between development, design and research teams.
When I was a kid, I was a big Bruce Lee fan. I walked around the playground rubbing my nose with my thumb. When I had a piece of rope, I had to do my version of the nunchaku routine from Way of the Dragon and made cat-like noises. Looking back at Lee, I find it quite striking how many of the principles of his fighting style Jeet Kun Do apply to agile practices. Check out these descriptions of the fighting style:
I am frequently asked by colleagues for advice on how to be a good Scrum Master. I will discuss some of the tips I share in a couple of blog posts. First of all I do like to state that I believe it's best to have a Scrum Master that is able to get his hands dirty in the activities of the team (i.e. coding, analyzing, designing, testing etc.). It will enable him/her to engage and coach at more levels than just overall process. In my opinion one of the most important things a Scrum Master has to do is to make things transparant for the whole team. Now this seems like very simple advice, and it is. However, when you are in the middle of a sprint and all kinds of (potential) impediments are making successfully reaching the sprint goal harder and harder, the danger of losing transparency always pops up. Here are three practical tips:
If you have a car, then every once in a while, you probably have your vehicle checked to see if it's still up to safety and environmental standards. So you take your car to the garage and have it checked. Now, the garage will do some tests and eventually you'll get a nice paper showing what kind of maintenance they have done.
Nowadays, cars are complex, computerized machines. (The days of dad lying under the car to do some fixing with some elemental tools are all but gone.) This means that as a customer, you will have to rely on the professional capabilities and integrity of the garage. You'll have to trust that if the garage says the car is fixed and okay, it really is fixed and okay. Now imagine that you went to the garage, received the paper that your car is okay, go on the road, and your car breaks down. What would be your reaction? You'd probably hold the garage responsible for this, as they are the experts and you paid them to do a good job. What would your reaction be if they told you that they didn't have time to correctly solve your cars problems and did a 'quick fix', without them telling you?
