Blog
Talk to the global leaders in fleet management, vehicle tracking and personal safety
Being passionate about testing and quality in the development process, I spend a lot of time with our QA Manager and have learned so much in the last 6 months. In any agile world, continuous introspection and improvement is a key aspect that ensures quality is maintained as we learn where we went wrong and how to do better.
I love story maps. I love that they are big and visible. That at one glance you can see what is going to be delivered in the next release. That everyone can see what is coming up next.
It worked really well in the beginning. It assisted our product owner in thinking about what he really wanted and thus empowering him to prioritise and communicate the reasoning behind that easily. Its up on the wall in the team room and everyone can see it easily.
There were some drawbacks though. As its up on the wall – its hard to move to a meeting room for grooming sessions. That also means the product owner cant use it when hes communicating to customers/stakeholders. Another problem – as the stories get groomed they split up into smaller stories and your story map grows exponentially – and the wall couldn’t be extended… The product owner and myself were the ones updating the board … and I would prefer the team more involved in this. I believe a team that owns a story map with the product owner is the ideal to strive for.
We tried the online story map which was awesome, but as expected keeping the online map and the real wall map in sync quickly became problematic. (Especially as printing out and killing forests is something I’m loathe to do). Here is another online story map tool, that I stumbled upon toolsforagile – also very nice!
A few weeks ago I read this blog post by Roman Pichler and decided to try some out-the-box thinking with regards to our release planning.
I loved the idea of boxing the themes (as opposed to columns on a story board). I also like the product and UI design parts – but would prefer them closer(?) to the theme they belong to. The constraints filled a gap that was missing for me – but again I wanted them closer to where they impacted a story. But this was enough to kick start my imagination.
A story map is a high level view of the application being developed, from a user’s perspective.
Story Mapping forms part of Release Planning, and is an excellent tool for identifying the Minimal Marketable Features (MMF) for the next Release. This is done with the Product Owner, ideally before starting the development of a new product, and then before each additional release.
To prepare for the Story Mapping session you should identify beforehand:
Declaration of the purpose of the meeting:
Reflect on the last sprint. How did you feel about certain things in the last sprint?
So, yesterday I sat with the Senior Scrum Master – or should I rather say with my Scrum Master, and went over some basic meeting rules to follow to run any review and retrospective. She explained a new method being used now in the next lot of sessions she is going to be doing for the other teams. The Product Owner can participate in the retrospective but they must not be allowed to dominate the session, cannot in any way attack the Team and the Scrum Master must interject if the Product Owner over steps the boundaries. The previous two sessions which I observed, followed a different method to the one I will use on Monday, but the same basic guidelines. There I repeated it again without explanation of what these ‘guidelines’ are.
The leader of the meeting, being a very abstract person in terms of approach to any subject, in the space of an hour taught me things that I am pleased to say will serve me well in my career in Scrum. In that session, Product Owners had brought some stories for “help and advice on” and actually take learnings from the discussion with this fairly gifted mind and go forth and conquer any business requirement thrown their way by the employment of simple guidelines. Alas, we move the great stones of the pyramids, with all our technology, slow…. even today!
Anyhow, I digress. Every time a story was read out to us that clearly needed some work, one simple response as it repeated enough times, began to resonate and strike that subconscious high-pitched note in my mind.
I love agile games – they make learning fun and interesting. Also people tend to remember the lesson as they experienced it.
I did a kanban introduction game at work with our support team who are using Kanban and our Development team is using scrum. Most people dont know what Kanban is or why we are using it – so the aim of this session was to demystify the word kanban.
To start off with I briefly explained that Kanban meant “Visual Card”, and that it was a pull as opposed to push way of working, that it was responsive to change and based on Just In Time actions. I then went through the core concepts.
This originally appeared on Sam’s blog, Inevitable
So its one month later… what has happened?
After 1 week we started adapting the board. The first change we made was to add blocks numbered 1 to 10 in the todo column so that it was clear what was highest priority.
After 2 weeks some more board changes occured…
The second change was to move to a bigger board! We had all the issues that were being worked on pre-kanban on the board, but we excluded them from the limits on the columns. The result was a really messy board.
The third change was to introduce a “parking lot” column. Many issues were with customers or hardware, and they got “blocked” stickies but were holding up the process due to column limits.
The fourth change was to add a swimlane for “pre-kanban” issues. This way we could easily identify the issues with the current support team and those outside of the team.
All of these changes resulted in a much cleaner board, and made adhearing to (and noticing) the limits much easier. One glance at the board could now show bottlenecks easily.
After 3 weeks we held a retropective with a representative from each column attending. In order to get feedback from all people involved we also sent out an email asking everyone who was involved for feedback.
The questioned asked were:
General feedback – overall for the 3 weeks how did you feel about the new support process?
Select one:
Happy ………….. OK …………. Disappointed
Other comments:
What worked well:
What can be improved:
What doesn’t work:
Any suggestions:
Important to note is that everyone agreed that making issues and bottlenecks visible on a board works well – better than any previous attempts at managing support items. YAY!
Looking at the data collected we then used dot voting to highlight which problems were most important to the group and thus needed to be addressed first.
These were:
Clearing the backlog – Currently the backlog items are piling up as we are limiting how many issues the support developers can look at.
Knowledge Transfer – There are a handful of developers with loads of domain knowledge. As such they do more or less everything around those domains. We need to start the painful prcess of transferring this knowledge. Naturally as the domain expert is not doing the actual work it will be slower. The suggestion here was to try dedicated time from the experts – 2 hours a day for 3 weeks.
Support Process Flow – documented. Whilst the kanban idea was explained to the first group of developers going through it – it has not been explained to the second group, so they were a bit lost for the first day or so. Also the testers in the support team have never worked in an agile way so the stand up routine is still a bit odd to them. We agreed to do a basic diagram of how the board works and what each roles responsibility is. This way anyone can look at the diagram and quickly come to terms with the new process.
One additional small item was actioned:
Template for sticky – each sticky on the board looks slightly different – and it does get confusing. We will put up a template (start date top left, end date top right etc) for people to follow.
Our standup process has changed. We were going around the group – each person saying his bit but that meant jumping around all over the board and it was very confusing. After attending a Kanban course our Support Manager made the suggestion of starting from the last column and addressing all tasks there then working our way backwards to the first column. This is much better!
Moving from right to left emphasises the PULL of kanban, we are also able to discuss blockages in any of the columns as soon as we discuss the column rather than waiting till the end of the stand up. After some internet searching I came up with a new format for our stand-ups. This is now printed up on an A3 paper and stuck up next to the board as a reminder.
Another contentious issue is when to do full solutioning, when to apply a quick fix and when to add a change required to the product backlog for the development team to do. We have decided to have this discussion after our first column (Dev Analysis) and present the choices with pro’s and con’s for the Support Manager to decide on.
To add a bit of fun to the board I created South Park characters with some space to scribble your name underneath. We have 3 of each character. So each person on support can pick one that personifies them, add their name to the bottom (it wipes off) and stick that on the tasks they are working on.
We started with 3 developers rotating through support for the duration of a sprint. The idea is to balance this evenly between all 6 development teams and rotate amoungst them so that everyone gets a turn to be in support.
We’ve had some good days and some bad days. All in all, based on feedback and observations we are all getting more comfortable with the new kanban process, and starting to make it work for us.
