I have been rather slack at writing for the blog in the past few weeks – seems that my day job as taken all my time and focus, so not much left for my poor neglected blog. So it doesn’t stay so so empty, here are some thought provoking words from a fellow agilist.
Agile has been around for over a decade, a lot of people are doing it, and that’s great.
But I see a lot of organizations struggling. Not so much with the tools and practices. But mostly in the mind – the head.
Here are a list of thoughts and attitudes companies need to get if they are going to truly adopt Agile as a means of delivery.
The plan is going to change
Plan the work, work the plan. That’s the mantra traditional project management has been teaching PMs for years. Except that it doesn’t work. Companies that expect software projects to be straight lines. But they look a lot more like this:
and it’s this unwillingness to change the plan that kills them – Agile or not.
Everyones has a plan until they get punched in the face. – Mike Tyson
Working in a large global corporation, it always baffles me how little we actually collaborate and utilize each other’s talents. I don’t mean working within my small team or even my extended product owner team, but across disciplines, teams and departments. Why do we hesitate so much to seek the assistance of others? Do we shy away from admitting that we could use some help? Are we afraid to lose control if we let others in on “our” area of expertise?
You might wonder what this post has to do with agile and well, perhaps it doesn’t specifically. It only crossed my mind since agile puts such a large emphasis on team work, collaboration, co-location, crossing skill sets… seems that these are all things we should embrace, not just on our agile lanes and scrum teams, but in our organization as a whole.
I try to encourage exchange of ideas by reaching out for help, offering to assist someone and most of all, genuinely invite somebody to challenge my point of view. I seem to get the best ideas when somebody challenges my initial approach and calls out my assumptions. I mean, as much as I would like to, I can’t be right all the time…and I am sure we can all benefit from a little more constructive feedback.
As it stands today, I think we have quite a way to go to communicate and collaborate successfully… There is a lot of talent out there and we can only to reach our full potential if we continue to challenge ourselves and others.
This particular piece is about Kanban and more specifically about designing a well functioning visual board to track your team’s progress. Like I mentioned previously, I am a big fan of visual management and display of information, but as Pawel rightly points out, team boards, whether for Kanban or Scrum, are only really effective if they are simple enough to be (almost) self-explanatory.
At the moment, I am helping out on a slightly different team on my project as an “adhoc PO”. While the rest of our project is pretty much scrum all the way, this team works a bit differently. They are not strictly setup as a scrum team with one scrum master and one product owner, as well as development and QA teams. In this case, because of the size of the backlog, we have a pretty large development team that makes it difficult if not impossible to support with just the one product owner.
The main focus for this team is our backlog of “next-in-line-but-not-necessarily-vital” items AKA product maintenance. All of the pieces on this particular backlog are important, relevant and need to get done, but they don’t or didn’t quite fit in any of our scrum lane work over the past few releases. The tricky thing is that all of these items are not as obviously related or structured as the rest of our backlog, hence making it much harder to properly prioritize and stack rank for the PO on the team.
Also, since this team is also responsible for supporting and fixing any new enhancements or bugs that user report or request, the backlog is nowhere near as complete or static as the rest of our scrum lane backlogs. Planning a backlog on shifting sand as it where, meant that our project leadership decided that perhaps scrum wasn’t quite the right model for this team, although they were very keen on continuing down the agile road.
Enter Kanban – a model out of the lean toolbox that is often adopted on the factory shop floor and at it’s most basic form features a just-in-time and off-the-top-of-the-pile approach to development. In essence, the backlog is prioritized and stack ranked and as soon as any developer has an opening, either because they finished their current story or because they have some idle time while working on another story, they pick up the next item from the top of the backlog queue.
Because of this model, stack ranking in Kanban is possibly even more important than in scrum, to ensure that the flow of work doesn’t stop and the production line never breaks. And this is exactly why we decided to not only assign more than one product owner to this team, but also went for the slightly unusual approach of having “adhoc POs” – such as myself – to lend a hand and help groom the backlog to make sure we can maximize the team’s capacity and effectiveness.
I really am looking forward to getting a little more immersed and learn more about Kanban vs Scrum – so far, it’s an interesting new perspective.
When I am writing User Stories and Acceptance Criteria, sometimes I really do wonder how my poor developer teammate is supposed to understand the garbled descriptions and instructions I put together. Sure, sometimes it so obvious, there is no danger of mis-communication, but more often than not, my stories are complex and complicated and convoluted.
Personally, I am a big fan of visual representation of what I would like to achieve. Actually, truth be told, I almost always draw a plan or flowchart of whatever it is I need to then put in writing. Not sure why, but when I can follow the flow of an arrow, I’m much more likely to find gaps in my thoughts, than trying to read through a script. Likewise, when trying to imagine changes in our UI, I prefer to create a few mockups instead of writing descriptions.
The downside for me is, that it usually takes longer to create a mockup or flowchart. Simply writing down what I want is absolutely quicker, but then again, more often than not, writing doesn’t accurately convey what I was trying to explain, so I end up having to go back and forth to explain anyway. After all, there must be a reason people say a “picture is worth a thousand words”.
Naturally, it usually pays to not rely only on my drawings or scribbles and I pretty much always write up everything, but I absolutely think that nothing beats a good visual aid.
I have spent so much time over the past few weeks reading, updating and prioritizing items on our product backlog, I feel like we could have literally built a whole other system at the end of it…
I exaggerate of course. The list is not that long, but it certainly felt like it at the time. It can be so time consuming when not enough care is taken to write down the requirements or problem steps in the beginning. Trying to decipher somebody else’s description of an item really is challenging, it almost seems like some of them are written in a foreign language. I mean, I know we have users in China, but i’m not sure that means that our backlog has to be written in what appears to be Chinese?!
Nevertheless, there’s only one way to deal with this and that is grit your teeth and fight through it. Unfortunately, diligently updating and prioritizing the backlog really does take time, far longer than I ever thought possible… and of course, nobody wants to wait until we have checked everything before choosing what we will work on next. Surely we already know what the biggest priority items are anyway, right?
Well, truth be told, at this point in the game, we don’t. By “we” I speak of our collective Product Owner team. Of course we each have our own opinion as to what we would like to get done first in the next release, but a clear and definite answer to what is the next big thing? No, I can’t honestly say that we have that. Not yet anyway. We have a good idea, we have a strategy and a plan to get there. What we don’t seem to have is enough time to actually do it. And I really really wish we did, because it is more than a little demoralizing to have to say that no, the list is not ready yet. Especially when most people seems to think that the one (and only) thing we POs are responsible for is that very same list.
After all that the top priority item on my new list will be this: a Backlog Button! 🙂
Something I find particularly difficult to deal with sometimes is how to handle all the suggestions, ideas and requests we receive from our end users. I am not talking about feedback regarding functionality that we are currently working on and where we specifically asked for feedback and user input. I am talking about all of those little things that users would really really like us to change or add to the application – particularly those that may not necessarily be a good idea.
Of course, users always have a specific reason in mind why they want the system to do something. However, not always are these requests really born from necessity. Especially in our case, where our application is replacing another system that many of our users have been working with for years, in some cases even decades. It’s no surprise really, that a not-insignificant number of enhancement requests could be simplified into one user story:
“As an experienced user, I want the system to handle this process the way my old system did, so that I do not need to change.”
Like I said, nobody is at all surprised that we receive requests like that, however somehow we haven’t yet figured out the best way to deal with them. Yes, we do have an extensive team of trainers, support staff and even a specific change management department, but requests such as these seem to bypass those teams entirely and in the end, tend to end up as enhancement requests in our product backlog.
For us product owners, this makes the process of prioritizing and grooming the backlog that much more difficult, because not only do we need to evaluate, prioritize and write user stories for all the very valid and great suggestions we receive from our users, we now also need to figure out what to do with the undesirable ones, who frankly just clog up our queue.
I do believe that the product team is responsible for choosing change – but we are probably not the right team to manage its undesirable cousins and the users who request them…