Translate

October 20, 2017

What's the story about those other user stories?

User stories expressing what the Product Owner or her Team want or need are bad practice. The PO delivers, never requests!


Summarising

Backlogs containing user stories that are catering for the needs and wishes of a Product Owner or Product Team are faulty. These kind of stories are unable to compete with stories that clearly add value to the business. By putting these stories on the PO's backlog compromise the ability of the PO to be successful. Instead these stories should be listed on a second backlog owned by the Team. This will improve the team's sense of autonomy, the Team's relationship with the PO.

In the past 6 months or so I've been actively working with agile teams on their backlogs. Specifically the Product Owners. As you might already know, I consider the Product Owner role as one of the most demanding and challenging roles within an agile environment. You might want to read my post on it, which you can find here. One of the major challenges I'm facing in working on backlogs is getting the Product Owner, and also the Product Team to understand why internal user stories are a bad-practice.

Internal user stories are those stories the PO wants, or the team itself. Most of the time, these are stories where an upgrade of some technology is needed, where technical debt is taken care of, or for example where the Product Owner wants some reporting from the tooling. There're any number of stories on backlogs where it is the Team or the PO in the 'I as a ...' clause of the story. Look at your own backlog and see for yourself.

You might have read my post "Perish or Survive, or being Efficient vs being Effective" on what agile encompasses in terms of motivation, or drive. When you commit to agile practices, you commit to effectiveness and in pretty much all cases you commit to a value-driven approach towards what has the highest priority.

Considering the above, than you realize that in most cases, internal user stories are not really creating value. Mind that you will have to consider the story and not the motivation for the story. Be pure in thought.
This is because of the simpel fact that the user, or customer requires and the PO (and her Team) delivers. That's all there is to it.

All of a sudden it is clear why a story like "We, the Product Team, want to upgrade to the next version of technology such and so, in order to reduce our technical debt" is a no-no on the backlog. Why? Because the user, nor the customer typically doesn't care and shouldn't care about the technology used.
Don't believe me? Well, have the user dictate the version of Ruby on Rails to be used in the development of an iPhone app and listen to what the Team has to say about this. I rest my case.
Having said that, it should also be clear that there is typically a more than valid reason why a Team wants to get rid of technical debt, even suggesting how to get rid of it as well. And in most cases it is related to the request of the user, demanding better stability, performance or security. The Team's story is an implementation aspect and nothing more.

Think about this a bit and then you're bound to see that when the PO or the Team will create their own stories and put them on the backlog, they will need to compete with the stories of the other stakeholders. Stories that add value, for the simpel reason that the stakeholders will ensure a clear value-add because that is what gets the story at the top of the backlog. (Provided the PO will actually prioritize the backlog based on business value and not things like vanity or volume of a voice.)
The last thing anyone should want is have the team's stories be relegated to the black-hole called "Tail-of-the-Backlog".

One of the most common ways of getting the things done, the Team wants done is by allowing the Team to spend some time on other things than stories. Sort of a budget expressed in time, the Team can spend on their own stories. I like to maintain the 80-20 rule here, as it can be applied in pretty much everything related to IT. So 80% of the time is spend on creating value, and 20% on something that is not necessarily adding value. How that 20% is allotted is up to the PO and her Team. Could be a day a week, could be two days during a two week sprint, or possible a full sprint once every five sprints.

I call it budget, because the PO's budget is expressed in time. She has a team available to her, a stable team paid for, for the lifespan of the Product she's owning. Consequently all she has is time to spend. Allowing the Team to work on their own stories, makes perfect sense. This is because the Team itself knows best on what stories are the most valuable. Whether it's the technology upgrade, the refactoring of old code or investigating some new concepts and their applicability.
Once the Team maintains its own backlog of its own stories, there is no need to compete with the stories of other stakeholders, the stories bound more clearly add stories. Moreover, the Team will more so be empowered to autonomously decide how stories are realized. Deciding when it is best to cut corners and when not. All of a sudden, the Team is not only responsible for the product's quality, but also accountable for the technical quality of the product.

The PO's backlog is one expressed in value creation, with the highest priority set to the story (potentially) creating the most value. Allowing the PO to be value-driven. The PO therefore can maintain a backlog consisting of user stories with clear stakeholders. People, not roles, that can be called upon to verify the product's ability to deliver value. And with the opportunity to ask these people beforehand how value is created, what metrics are needed to validate the product's benefits, etc. And of course, the story will contain the name(s) of the people to explicitly invite to the Team's demo of the product.
The Team's backlog at the same time can be prioritized on the account of what will reduce the product's costs the most. Accommodate for future developments as well as operational aspects, etc.

Maintaining both backlogs also strengthens the relationship between the PO and the Team, putting the emphasis on trust, accountability, facilitation and empowerment. The corner stones of agile teams.



Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

October 9, 2017

ASAS2017 in hindsight

ASAS2017 in hindsight

A couple of days ago, Thursday October 5th to be exact, I attended ASAS2017. It was my fifth attendance of the Agile Software Architecture Symposium.

Summarising

This year, as part of keeping a promise, I did a presentation at ASAS 2017 about Agile and Architecting. Adapting the presentation up to the last minute based on feedback I garnered while attending other presentations, I felt really agile.
One of the key take aways for me was that doing a Kahoot! to know the audience instead of raising hands makes a lot of sense when you want to know who your audience was. But you need to keep those stats. And it's almost imperative to have a clear means of being contacted shown on a slide. At the end.

A couple of days ago, Thursday October 5th to be exact, I attended ASAS2017. It was my fifth attendance of the Agile Software Architecture Symposium. This time around I was one of the speakers. It was a promise I made last year to the organizers. The promise was that if 2017 would have an ASAS, I would submit a proposal for a talk and if it would happen as such, I would be one of the speakers at ASAS 2017. Promises are there to keep, so I kept my promise.

Funny part, although at the time I really didn't think it funny, is that just days before my family and I would drive to Croatia for our summer vacation I checked when in November ASAS would be this year. Yup, I was mistaken by a month and the date was instead of somewhere in November, some time early October. The 5th to be exact. And apart from my submission in early April this year, I had nothing prepared at that time.

The topic of my talk would be something about architects being able to survive in an agile world. Something I am talking about almost on a daily basis with clients and especially their architects and agile coaches. But since April I had changed my story continuously... based on the feedback I got during those discussions. Understanding what works and what doesn't is important and crucial when you're coaching. So it was more or less imperative that the contents of the talk would be significantly different when compared to my initial view on the matter in March and the presentation I would give on the 5th of October.
Just to give you a hint, this is what I proposed in April:

How architects can be successfully agile.

Summary: Architects are known for their talent to ensure that projects run out of budget or out of time. The best of architects are successful in ensuring that projects run out of both time and budget. But with the advent of agile practices and the agile manifest, architects are no longer needed, they have no longer a role in continuously postponing a project and ensuring that tons of money are wasted. With waterfall becoming water under the bridge, there is no longer a need for procrastination by the architect. Unfortunately, as evolution goes, architects are genetically inspired to build ivory towers. Doomed to follow the path of the dinosaur. Unless... unless they manage to become agile. This session is about how architects can become agile and thrive again, gaining the respect of... well pretty much everybody and their mother.

When I set off on this journey, I figured I would talk about architects and how they need to change their attitude and way of working. But over the course of the months since April I realized more and more that it's not the architect that needs to change, so I adapted and changed my presentation.
In fact I changed my presentation even 10 minutes before I had to go on stage and give it. Truth be said that in those final minutes the changes weren't significant, yet they were adaptations to feedback I got while attending other presentations that day.

I started of with a Kahoot! to get to know my audience. Instant feedback in terms of laughs meant to me that it was a good way to break the ice... but since I forgot to save the results and in the first place to test the quiz myself, meant that I don't have the right metrics to judge the appropriateness of my slides.

I ended with the opportunity for my audience to ask questions. And that was when the room stayed quiet. Silence. No questions. Not a captivating story that was raising questions. Until a question was asked. By one of the Arc-E-Tect blog followers. There was the answer, and that's when the questions came. And people stayed afterwards, wanting to know more. And then there was the after-party and more people wanted to discuss the presentation.

So in hindsight, the presentation went well. It went well considering the metrics I had set for myself up front. How many people would be in the room, how many would leave during the presentation, how many would join the Kahoot and how many questions would be asked during the presentation. And finally how many would want to talk about the topic after the presentation was done and they had ample opportunity to talk about other things to other people. In all cases it was beyond expectations.
Considering my expectations; the Kahoot! was about getting around 75% of the audience to join, which I think was achieved. I don't have numbers about the audience. Considering people leaving the room during the presentation, I only saw 2 persons leave in a room of about 50 people. Considering questions asked, 3 questions was for me the minimum, based on the fact that I thought I would have time to spare for questions and the story was compelling. 4 questions were asked with 4 different persons asking more questions.

All in all I feel that my presentation at ASAS 2017 was a success, also as an experiment to see if you can consider a presentation to be a product that adds value and can be done in an agile way. 

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

August 4, 2017

The "Eat your own dog-food" fallacy

Why having people eat their own dog-food doesn't accomplish anything sustainable.


Summarising

Having somebody eat their own dog-food doesn't necessarily make the improve its taste but might make them get used to the taste instead. Awareness of the (lack off) quality in one's work is important when transitioning from a Dev/Ops organisation towards a DevOps organisation. But experiencing a lack of quality first hand is often not the way to do so, or even an option. Agile transformations are only possible by means of cooperation.

There's a common understanding in the world of organisations that are transforming from Dev/Ops towards DevOps organisation that this works best when the devs are forced to eat their own dog-food. It's a reaction from the Ops people towards the Dev people.

Basically it means that once you've got the Devs supporting their own products, they'll make sure that those products are of a high quality. Common believe is that since they, those Devs, don't want to get called Sunday night at 3 AM because their software crashed. Which makes perfect sense, who does want to get called Sunday night at 3 AM because something they created crashed? I wouldn't, would you?

So, if you want those Devs to focus more on quality, on less crashing software, you have to make them support that same software themselves. In other words, turn those Devs into Ops people and that'll show them.

About a year ago, I joined a team at one of my customers to help them transform selected development teams into more agile teams utilising Continuous Delivery mechanics and move towards, lord forbid, DevOps. One of the slogans we used to get the necessary buy-in was:

"Eat Your Own Dog-Food"

And later we added "And Clean Your Own Shit!". Totally convinced that this is how it works. Make people feel the pain they're causing and they'll become better persons. If you would do a little time-travel and rewind about 2 years, you'll hear me saying that "one should feel the pain they're inflicting".

I think you'll recognise this when you've been in that situation where you want to move from Dev/Ops towards DevOps. Or become more agile. Or maybe you need to convince people that agile or DevOps is the way to go.

It makes total sense. People with kids know this. You want them to stay away from the fire, let them burn their fingers. Or those people with dogs shitting all over the place... let them clean that shit every time their dogs drop their poop in the playground. It works, really does.

But there's a huge problem in this, I'll get to that. First I want to ask you if you've noticed that slightly grumpy undertone in me mentioning of the "Eat your own dog-food" slogan and everything associated with it.

Agile and SCRUM in particular are developer driven ways of working. It's the developers that want to change things. Reason, obviously, is that developers want to develop software that people are using, so they want to get create something that is as close to what is usable as possible. Meaning that they want so put something in the hands of the user as quickly as possible and then make adjustments and put that into those same hands. And again. And again. And again.
Our organisations are such that specialised Ops people are managing those applications when in the hands of those users. And they need to keep up with all those adjustments... You understand the predicament those Ops people are in.
So when you tell these Ops people, that you want on your side while transforming into agile organisations that those Devs should eat their own dog-food. Ever tasted dog-food? So how do you think that this resonates with those Ops people? Pretty awesome, don't you think?
That connotation of dog-food is getting the nay-sayers called Ops on your hand, shouting "Yay" instead of "Nay". Mission accomplished. You're done.

Well forget it. That's the "Eat your own dog-food" fallacy. It's a fallacy because it doesn't solve anything and it certainly won't help you in your agile transformations. Considering your organisation has separate Dev and Ops teams, and considering that the reason for this is a more efficient Ops team because they will support many products. Because supporting a quality product is not a full-time job. Read my post on this topic. There's no way that having the Devs eat their own dog food will improve quality. Which was the premise in the first place, remember? And now you should say that in fact it doesn't make sense at all. Because there's an Ops team and for a good reason. So what makes you think that anybody in the organisation will just allow the Devs take over the Ops jobs? Ain't gonna happen. No way. Meaning that whatever you're trying, the Devs won't even get the opportunity to eat their own dog-food, even if they would want to. You can fix it by job-rotation... in certain situations, in certain organisations. Fallacy explained.

Considering the above, how would you need to address the agile transformation? How to move towards a DevOps setting? The answer is quite simple and probably extremely hard to implement. The more alluring the "eat your own dog-food" approach is, the harder it will be to do the correct thing. The sustainable approach, let's call it.

If you want the developers to develop software of a higher quality, you need to make them aware of the problems they are causing because of the lack of quality in the software. And you do this, by introducing them to their operations colleagues. Let them work closely together. Geographically close. As in side by side. Not pair programming close, but across the desk close.
What will happen is that the colleague from Ops will complain to his Dev colleague about a problem instead of to his Ops colleague. Feedback loop is tiny and closed. And most likely, it's friendly constructive feedback, because it's directed to the immediate colleague from across the desk. That person with whom lunch is shared. Not bottled up feedback. It becomes a feedback loop in which the Dev can immediately ask the Ops person why it's such a huge problem, this tiny thingy.
Getting the Dev and the Ops to work at the same desk, allows them to become aware of each other's work. And generates understanding. Understanding towards their respective worlds. It creates an atmosphere where the Dev will improve the quality of the product, because otherwise the Ops colleague is called Sunday morning 3 AM, and that's not something the Dev wants.

As a parting gift, another tip: Make sure that Devs and Ops don't huddle together when you put them in the same room. Instead put the Dev next to the Ops, side by side, hand in hand. When you allow them to huddle together, you should put them in separate rooms. Just to make sure that their respective complaining is not effecting them during work hours.
By allowing those to blood-types in your organisation to become aware of each other and befriend each other, you'll pave the way to become a true agile organisation with a smooth transition towards a DevOps mindset.

Here's an exercise for you: See how it works the other way around. Feel free to use the comments to discuss.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect