Mind maps from some sessions at Agile Adria 2015 held at Terme Tuhelj just outside of Zagreb in Croatia. They are rough but still good memory joggers. More may flow from these depending on time.
Tag Archives: Lean
My company, About Agile, is now offering Agile Assessments using the Agile Journey Index. If you’re interested in starting your journey or just improving along the journey this is a great way to start and About Agile can help you along the road as well.
More information is available at the Agile Assessments page on the About Agile website.
Our Agile Perth meetup had renowned guru Martin Kearns in town last week and we were able to witness him give a talk to our group. Martin wrote a section in Chapter 13 of Lyssa Adkins book Coaching Agile Teams. I got out a lot out of what he wrote there so I was keen to see him talk as well. These are my recollections which could include my own opinions and interpretations. As always refer to my policy on such things can be found in these posts: Ask How, I merely state and Take Notice. Comments are of course welcome.
Martin’s talk entitled ‘The Lens‘ begins by describing attempts to create adoption as more like shaming people into change. We do this through out many facets of our lives starting from when we are kids at school suffering from reprimands for ‘incorrect‘ behaviours or actions through to adult life whereby we are driven to fear risk (or so called).
Martin offers up another way to produce meaningful change through the act of ‘Story Telling.’ Old cultures passed knowledge down through the generations via story telling. We heard about the Irish legend of Setanta and the hurling story. That story was passed down by a professional story teller called a Seanchai. The culture recognised the importance of passing down knowledge and created a role for it. Australian Aboriginal culture using dreamtime to pass down ‘lore’
So organisations should be creating a space for story telling. These stories if successful spread like wildfire and become the folklore. They become part of the innate corporate knowledge and people can identify with these.
Storytelling is the basis for what Martin calls the ‘The Lens’ We cannot solve problems through what are ‘dominate logic’ or mores, a cognitive bias that prevent us from seeing the unexpected. These constrain and prevent us from seeing other solutions, new products and new ways of working. Dominate Logic could be likened to the the disorder segment of the Cynefin framework whereby most of the time we fall into that area and use our bias to select, often usually, the incorrect problem solving method.
‘The Lens’ uses the tools of sense-making and through this process all ideas of hierarchy need to cast aside as an idea come from anyone. There is a release of pressure that fosters creativity and shuts down dominant logic. A space is created for this to occur and the recommendation is that all organisations should provide this space (as seen from Australia Post). From this space stories can have their genesis and ‘Inspire Action’ Hierarchy prevents flow of information, even blocks it. A better way is to have a network of information flows that is more representative of true connections within the organisation.
When stories resonate through the organisation that’s when real problems can be solved. There are tools to create and maintain resonance like a Celebration Area/Room and area where the wins are on display. The visibility of the area helps creates resonance, hiding it will have the opposite effect. For example, when the area was empty the story reverberated around the organisation when the CEO (I think) paid a visit. Seeing the emptiness inspired action driven by the CEO. In this area anyone is allowed. For example, a Customer Care person spotted an issue that no one else could.
Sense Together, using the same language – the language of the business ==> Real Needs can emerge from Shared Meaning ==> Together we discover a Route to true Change
In the room, emotions are allowed. The room safety is sacrosanct. We want all ideas in whatever way they are expressed to be surfaced.
In the room, the Enterprise Kanban Wall only contains Questions and only the sponsor is permitted to move a card, not a PM not the PMO.
Solving complex problems cannot occur through a filter of neatness. You want everything visible including the bad stuff. Let is all out – allow the duplication, allow the ludicrous, allow everything. Find the patterns, make the corrections and remove the duplicates later and use peripheral vision to make the connections.
Have a look at the presentation slides as well. This is just a recollection of my thoughts during the presentation. There is definitely something in it, and I’d like to incorporate facets of it in my work. Martin also told us about paying a caricaturist to capture events to be placed in the room. The cost of this is far outweighed by the benefits that were ‘drawn’ from the pictures.
To really make a difference it takes these sort of thinking outside the box moments to occur.
ScrumDo is another online tool for managing work. It competes in the space of tools like LeanKit, Jira Agile, Kanbanery, SwiftKanban and a host of other tools from other vendors. The differentiation it appears to me, is that ScrumDo is slanted to a (outright) ScrumBan view of the world, combining aspects of Scrum and Kanban in what could be a much stronger product than some other offerings out there (my experience is only with LeanKit, Jira Agile and TFS/Visual Studio – not a huge amount :)). You could run a Scrum, Kanban or a ScrumBan – and you can in other tools for that matter, but the features in built in ScrumDo make it appear or feel more targeted to this.
Here in Part 1 of a series of posts I describe the setup of the first iteration of a project I’m currently running. In a previous post on LeanKit, I noted that I lacked a proper breakdown of tasks for big items on my Personal Kanban that was causing some morale issues – although I did get to end with flying colours, it’s not a way of working I recommend.
Note: I include many screenshots. I recommend clicking on the image to get a clear view if you so desire.
Cleaning up the Previous Board
I did a board for the previous project but it fell into disuse. I decided to clean it up. The standard board presents two horizontal lanes, an Expedite Lane which anyone from a Kanban background will recognize and a lane for the current iteration. Here’s what I started with and you can see the expedited column is blank. It’s hardly used and I didn’t want to use it so a later view you will see that I removed it.
I used the Iteration Planning Tool to move items, but you can also use the above view:
Cleaning up the Board – the Board Editor
I removed the Expedite column in the Board Editor, a view of which is shown here. Subsequent to this I’ll show later on some other edits that include WIP limits, effectively ScrumBan-ing the board, and adding policies under the columns like Definition of Ready for stories and Definition of Done for development tasks.
Epics and Stories
The first thing to do was create the Epic and Stories. I’m following standard scrum backlog grooming practice and I created the Epics and Stories. As this a project to create course material for an ICAgile accredited course for my company, About Agile, the Epics and Stories followed the layout of the ICAgile learning objectives for the most part. Easily filled in – not a big Release Planning session required for this project 🙂
There are a number of views for creating Epics and Stories. Here is the Backlog view:
And here’s from the Epic Planning View:
With a Release plan created (though Epics and High Level Stories and no more) it’s time to create the first sprint/iteration. The first iteration was already created as shown above and is also a way to setup an iteration. There is also some setup that can be done – interestingly one can set resource availability in hours – I wonder if this fits in with #NoEstimates 🙂 , something for later. The steps correspond roughly to part 1 of sprint planning as you’ll find in the scrum guide.
Along the way you may find that you need to change things around. For instance I needed to to convert a story into an Epic (I’m playing multiple roles being the only person on the project – PO and Developer and ScrumMaster):
I also had to move a story between Epics. This can be done in the Edit Story view. Notice standard Fibonacci Series relative estimation can be changed here (as well as elsewhere):
And also through a specific view that converts a story to an Epic. In this example I found I needed further breakdown and hence converted the story to an epic:
Sprint Planning Part 2 – Some Task Breakdown
Here I’ll show some view that allow the first few items of the sprint to be broken down. I don’t break down everything as the July 2013 version of the Scrum Guide guides us to do. I just setup enough to get going and start producing, also leaving some room for the innovation. This view shows I’m actually working on the sprint planning tasks:
And this one is showing how desperately hard I’m trying to think of the tasks that may be required for a task. Inevitably there will be something I missed:
and as always – I try and use a pomodoro/tomato timer – I sometimes forget that as well. Here I’m taking the time to take a break during sprint planning, but maybe if your doing this in a group you’d space the pomodoro to longer than 25 minutes:
Done some editing of the board whilst I created the Sprint Plan
Here I present some editor views. As I was creating the plan and learning the features available in ScrumDo I changed things to suit the desired way of working. Here I removed the Expedite horizontal lane and added WIP limits. Most columns use points for limits except the Done columns which are using card count to force a pull into the next column of the value stream. Will see how that pans out.
In this view I’m adding a Policy and a WIP limit for the TODO column. This view is accessible via the board editor:
So I got to the end of editing the board and sprint planning and the board took more shape with the first 4 tasks, the most important, having been broken down:
Advisable to have a Sprint Goal
Yes you need a milestone to aim for and I recorded mine as part of the sprint planning task and used the time recording view to keep track of the time I spent. As far a time spent, I’m not really sure I want to 1. Give a time estimate and 2. Record it. Fighting off Parkinson’s Law and Student Syndrome is already hard enough. Time estimates can be taken as targets and both of these dysfunctions can kick in.
Extras: Policies show up as tool tips
This policy is quite big and not easily view-able. Not a big issue.
This one looks better, not so big:
So at the End of the Day
So I did my sprint planning and fixed up the board as shown above in the selection of screenshots. I made a start on the tasks and found that having the smaller milestones and thinking about tasks drove more satisfying outcomes. The experience of the previous work, which I’d not done before, was a good input and I have adapted from those experiences. Having something to aim for what certainly helpful on this first day.
New projects almost always start off a bit haphazardly as all participants find their feet. This really is dependent on how new the domain is and team forming attributes of a new team The trick to to reflect and adapt, something all too often forgotten or put in the too hard basket. It’s OK to feel unsure at the beginning, but don’t let this drag on. Take action to remedy the situation. It may take several goes at it, but as long as a culture of safety exists, you should be able to take out some very valuable lessons and this is very important to build further from.
Here’s the board at the end of today for this project (BTW: this task, to write this blog, is on my personal board and not this one :))
In subsequently posts I’ll describe new features of ScrumDo as I come across them. It will interesting to see what metrics and reports I can get out of it.
Note: You can now read Part 2 of the series.
These sort of cartoons are popping up very regularly on LinkedIn. I also get it in conversation as well – ‘we’ll look at it in 6 months’
Actually being too busy can mean that you are taking longer to deliver – see the multi tasking name game from Henrik Kniberg for an excellent example of a game you can play to illustrate this point.
Now for the plug, I provide services that are the wheel. My company About Agile can help you improve.
|Click on an image to see a higher resolution version|