Tag Archives: Scrum

The Importance of Shared Purpose

My latest blog is actually one written for my employer here in the United States, Code Genesys.

You can take a look at it here and is on the importance of shared purpose.  Keep practicing that because it’s hard for first timers and anyone whose experienced for that matter.  Well worth the investment in time 🙂

I have an example of a company who go to great lengths to maintain their purpose.  An old blog article written 2 years ago.


Avoid the Workflow Masquerade

Here’s a tip for scrum teams.  You are almost certainly using a task board.  If not start today.

That task board typically consists of the standard TODO, Doing, Done style.  Sometimes you will see the Doing column divided up even further – some mature teams realise that but a lot don’t so here comes the tip.

Simple Board

Typical Simple Board

In doing sprint planning or planning for a User Story the team identifies a number of tasks required to complete the story.  For example, perform detailed analysis, code the UI, code the business logic, perform testing.

It turns out to be quite a laundry list of tasks.  Within that list is always a pattern.  That’s right always.  All your user stories almost certainly involve a component of analysis, coding and testing.

So the tip is to make that visible and stark to everyone viewing your board.  Evolve from the three column format of ToDo, Doing and Done and divide that Doing column into Analysis, Code and Test.

More Workflow Board

Go for this.  Workflow is visible

Whilst your at it, define some common policies for those columns.  For instance for coding – code and test UI, code and Test Business Logic layer and so on so forth.  That’s called your Definition of Done.

What does this do for the execution of the sprint?  Here are several things it can and should do.

  • Sprint Planning becomes more focused on asking real pertinent questions about what’s coming up rather than diversion on getting the laundry list together.  You could really ask the what if questions of the Product Owner and making a deeper start in technical implementation details and discerning the risky parts of the work.
  • Make the flow of work more visible.  This will increase the effectiveness of daily standup.  Speaking to the cards on the board and seeing where they are at, how long they have been in a part of the workflow causes more transparent and focused discussion of the work.  Of course the team should be willing to discuss the reality of the situation and some will refuse to do that even when it’s staring them in the face.  Note:  This is when the real rubber hits the road – the Scrum Master, Agile Project Manager will be willing to seek out help the team discover the causes and deal with the organisation impediments.
  • Show the real time for each part of development.  This can help the team improve on specific problem areas.  Because there is real data for each point of the process, the team can choose where to focus their improvement efforts to decrease the overall time to deliver.

So you may ask.  Is this Kanban.  The simple answer is no.  A Kanban System has more components – most importantly WIP limits on workflow steps.  However use of a these ideas more readily found in Kanban systems will still create visibility.  Evolution to more flow based systems could be an end result or perhaps just a hybrid like Scrumban.

So avoid the workflow masquerade.  Make those tasks into workflow and get on with real work.


Scrum Shortcuts the Video Series from Ilan Goldstein

Aussie Scrum expert Ilan Goldstein has made the perfect accompaniment to his handy book of scrum tips called Scrum Shortcuts without Cutting Corners.  It’s very handy reference to anyone wanting to get through those tough episodes we all experience in product development with its slant clearly on Scrum – I find the tips to have a universal appeal as well.  Here’s a bit of a summary and teaser for you to try the video series yourself.

On FrontRowAgile Ilan talks us through his tips and experiences by diving them up into five broad categories.

  • Planning and Protecting
  • Requirement Refinement
  • Establishing Estimates
  • Monitoring and Metrics
  • Reviews and Retrospectives

Planning and Protecting

Here we get tips on Sprint Planning.  Scrum tells us to do this to set up a goal for a team to deliver value to their customers.  There is important psychology that backs this up.  To quote Tim Lister and Tom DeMarco – ‘Providing lots of satisfying closure, one of the key elements of a chemistry-building strategy for organisations’  Maintaining a rhythm via sprints and the ceremonies within helps teams achieve results.

Visual representations help a lot.  The brain processes visual information 60000 times faster – from what I hear 🙂  So it follows that it would aid human psychology.  It’s more stimulating and we gain information just from passive observation.  So the task board is a central part of Scrum – actually the Scrum Guide tells us to use any visualization that makes sense and the task board almost always does.

In addition to this other visual artifacts help us like the sprint burndown and a prominent display of the Sprint Goal.  It becomes part of the team’s rituals.  Place them near the board.

A sprint is never without hurdles.  Visualize these (risks) as well.  A memory peg helps to CONTROL your issues.  The acronym helps as follows:

Confirm, Triage, Remove, Outline and Learn.  – Ilan explains more in the video 😉

Requirement Refinement

It’s important to divide stories into tasks.  A mistake is divide stories on a technical basis.  It’s common to see UI, Business Logic, Data Logic splits across an entire story.  Find a split that delivers a slice of functionality that cuts through the layers of technology and deliver that.  For example username/password of a Login story.

Sometimes we do need to deal with a technical requirement.  Try and fold those into something that is useful to the customer.  The use of user story format for technical stories is a bit of square peg in round hole.  Don’t sweat that if it happens.

A word on completing those stories and tasks with the well known definition of done.  That checklist that a team uses to ensure that when they say they are done they are done.  The team creates and owns this, but we do expect to see similar items across many software teams. Examples like unit tested and peer reviewed.  The DoD operates at task, story and release level – have one for each level.

Establishing Estimates

We learn about using story point estimation.  It’s useful to factor three planes into the estimation, namely Complexity, Repetition and Risk.  We don’t need detailed specs, rather other items to compare against – that is benchmarks from historical performance (or fake it til you make it – i.e. till you create history, use your best guess).  We learn about the approach to Planning Poker – a big take away is to incorporate diversity and it’s a common pitfall to assume experience is all that counts.  Some tips are provided on planning poker – rather than repeat them all (you should watch the video for that) some are re-estimate classes of stories when discovery of a wrong estimate occurs and to facilitate respectful debate on differing sized stories as opposed to a deconstruction.

Monitoring and Metrics

Metrics need to matter – rather than metrics matter.  They are a guide to inspect and adapt and not a tool or wedge against individuals.

Many teams find the sprint burndown chart to be useful as a guide on progress.  Used honestly it will highlight issues visually that a team can use to correct itself during a sprint (i.e. we aren’t going so well) or for when more work can be pulled in (we are doing well).  The same can be applied at the release level as well.

The daily scrum is an important monitoring ceremony. An effective standup is pivotal to being able to move tasks do a done state through the three questions (What I’ve been doing, What I intend to do and What is blocking me).  Keep it short and on topic and agree to fix issues outside the event.  To keep it interesting try by energising the event like throwing around a toy and change that up when it starts to wane.

Early and continual walkthroughs during the sprint are important for feedback from the PO and from others.  It will make the Sprint Review more of a tick and create a more valuable experience when that event occurs because it can focus on outcomes and looking ahead.  A walkthrough is a checkpoint that keeps us within the sprint goal and on track.

Reviews and Retrospectives

The Sprint Review is a momentus event and should be handled as such.  Be prepared with Demo Data and a real staging environment and not smoke and mirrors – the PO could say to roll forward to production with the increment.  Let the attendees know beforehand with an agenda and ensure the location is booked and setup with all that is necessary like a whiteboard and the hardware.

When running it consider it more like a collaborative workshop rather than a demo.  A two way exchange is therefore encouraged. Keep the meeting on topic with off-topic conversations acknowledged and agreed to be parked for later.  The development team gets a feel for what’s coming next and is able to ask questions around that.

Those receiving the product increment get a feel for how the team went about the delivery fostering an empathic view of the effort.  An enjoyable review is an indicator of success.

With the retrospective, the team has it’s all important opportunity to reflect and celebrate it’s wins and also to think deeply about where it can improve (invite the PO as well).  Ironically when the pressure is, is when it’s most useful.  Scrums values really do come into play in this event:

Scrums Values

Scrum Values

Some popular topics for focus are around communications, process, scope, quality, skills, environments with an aim to have actions that can be delivered in an upcoming sprint (don’t do them all if there are many – rank them).  Keep those actions visible near your task board.  A couple of interesting retrospective techniques are represented (circles and bubbles) with these suiting newer teams – with mature teams, just shooting the breeze works well.

Conclusion

Doing Scrum is more than going through the motions.  Ilan conveys throughout the videos this ethos.  Look deeper, be prepared for the hard stuff and learn from the experiences and everyone will be winners.  This video series will help with great tips to aid in your scrum and agile journey.


Managing work with ScrumDo – Part 2

Continuing on with a series on ScrumDo, a board that is not as well known but sure to still gain more users especially for those that want to evolve their Scrum implementations.  You can read first article in the series here.

In this article I’ll present some extra features that I’ve discovered over the course of running several sprints over a couple of projects.

Multiple Sprint/Iteration View

In this screen shot we see multiple sprint views.  Selecting from the drop down we can check the iterations/sprints we’d like to see visible at one time.

Can view multiple sprints

This is been useful to move incomplete stories into the next sprint and to get a view of sprints over a release.  Here’s an example:

Use Multiple Sprint View to move to new sprint and some items into the input queue

Exceeding a WIP Limit

Here we can see the Doing/Done column has had it’s Work In Process (WIP) limit exceeded with the WIP value shaded in Pink.  This means I should really be pulling into Reviewing.

Done Column exceeded - need to pull into review - found I didn't need 52 as such because I was documenting as I went

I found that a the Doing/In Progress column WIP limit, based in Story Points, was too low.

Exceeding a WIP limit - will need to adjust it's too low

I eventually increased the WIP Limit as shown here:

WIP now set to 4 SP (If I stop using SP then I would have to switch to cards)

Scrumban for more flow

I found that I could progress to a more flow based replenishment of work, still within the context of a iteration.  No it’s not Scrum, it’s ScrumBan – at least I think it is.  I’ll leave it to others to decide on what is ScrumBut or ScrumBan (please leave a comment).  Teams can work out the best process for themselves from a sound basis.  In another project with another person we find this style works a lot better for the context we are in.

Scrumbanning - pulled in from Input Queue - fastidious scrum wouldn't permit this

Tasks can be Visible on the Board

A colleague and I found that having tasks with a story visible in some columns aids in visibility.  We used the board editor to amend the doing column to have this.  You will also notice buffer columns added to more visibly display that items were ready to be pulled into the next part of the value stream.

Reorganizing for Sprint 3 - partway through

Now for some Requests

Acceptance Criteria

It would be nice to have an explicit area for Acceptance Criteria.  We utilized the comments to achieve this, however it’s easy to lose them amongst the other comments.

Would be nice to have a section for Acceptance Criteria with Checklist, using Comments for now

Story turned out to be an Epic – keep the comments

Sometimes stories are too big and you do not realise this until later.  Now this can be tackled by improved story breakdown and this does happen, however stuff happens and things slip through.  I had one such episode where I had several comments against a story.  These turned out to be more like splitting comments, so I wanted to convert the story into an Epic.

I did this but I lost the comments as a result.  There were quite a few.  The friendly support staff restored a backup but it was too late.  My changes occurred with the window between backups.

Cool Features yet to be tested

ScrumDo has extensive integration with other tools.  GitHub integration looks cool, up against other tools that do this as well like waffle.io

GitHub Integration 1

In upcoming posts I’ll show some more features like the reporting capabilities.  For example Cumulative Flow Diagrams.

A colleague has told me that he is liking ScrumDo.  It has more flexibility than tools like TFS.  Still some quirks, but overall we are pretty satisfied with the experience.


Managing work with ScrumDo – Part 1

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.

Board

I used the Iteration Planning Tool to move items, but you can also use the above view:

Iteration Tool - Movinf Current to Completed

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.

Editing the board - want to remove the Expedite lane for this project

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:

Adding Stories to New Iteration

And here’s from the Epic Planning View:

Epics planned out - feels like 2 to 3 two-week iterations worth of work

Sprint/Iteration Planning

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.

Iteration Planning - Resource Allocation

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):

Converting Story to an Epic

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):

Move to another epic

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:

Converting 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:

Planning, cycling between choosing and how to do the work

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:

Tasks - trying to think of everything

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:

Taking a Pomodoro Break during Planning

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.

View of new Board with WIP Limits and removed Expedite Lane

In this view I’m adding a Policy and a WIP limit for the TODO column.  This view is accessible via the board editor:

Adding Policy and WIP Limit for TODO column

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:

Created Tasks for first few days of the sprint

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.

Added the Sprint Goal as part of Planning

Tracked time for Planning - but you should save any edit before doing it as I lost my sprint goal comment when I clicked first time

Extras: Policies show up as tool tips

This policy is quite big and not easily view-able.  Not a big issue.

Policy Defined for Doing Column - possible issue with tooltip to fix

This one looks better, not so big:

Definition of Done for the Review Columns

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.

Status at the end of the first day - will not pull into review until we need to

Note: You can now read Part 2 of the series.


Professional/Certified Scrum Developer – Lamentable Takeup

Recently Ken Schwaber posted on his blog about perhaps licensing Software Developers and those who practice in the field in much the same way we license other professions.  The even greater reliance on software these days requires even more reliable delivery of that software.

I somewhat agree, but I don’t think the rest of the world does.

I looked at the PSD certification that Ken’s scrum.org provides.  Scrum.org certifications are the more difficult ones out there and is a deliberate response to toughen up the certification space.  For the PSD certification there as of 11 May 2014 only 1341 holders.  This compares against 21,112 who hold the PSM 1 certification.  I could not find any figures for the Scrum Alliance’s CSD certification, however they have some 300,000 holders of their comparatively easier CSM certification.  Given that there are only 74 members of the CSD linked in group the ratio is probably similar.

Why is this?  Looking at the reading material for PSD course though, it’s quite large with 29 books listed.  I’ve read all but four of these books and this has taken a long time over a long period of time.  I do intend sitting the exam as well but only when I feel absolutely certain I’ll pass with a score around 95%.  The test is 80 questions in 60 minutes with a pass mark of 85% – the hardest of all the Agile certifications (those only involving an online exam) that I’m aware of.

So the difficulty in the exam and it’s sheer volume of content could be a problem.  But there are courses in PSD that run for 3-5 days depending on who’s offering it.  But there are hardly any offerings on scrum.org at the moment.  It would seem people aren’t clamouring to be do the course.  Supposedly this would put you in a good place to pass the exam.  I do wonder if this is the right way in any case.   Granted courses are good for learning something that you may not have known previously but maybe should not be viewed as a shortcut to certification.  Some experience component is required.

So taking a course is not high on the agenda.  Perhaps there are people who’d like to take the course but can’t because their employer won’t allow 5 days away.  Generally this could not be the case as all employers allow time for training.

Is it the content – yes there is a lot.  The quality could/should not questioned.  The authors and the books are well accepted.

Maybe what Ken suggests is correct.  Forcing a licensing approach could create better developers and improve the state of software delivery.

 


Review: Scrum Product Ownership by Bob Galen

As Bob rightly says there’s not a lot of coherent writing on the role of the Product Owner in Agile.   One of my previous blog posts outlined the importance of the role, but then also provided links to find more information from guys like Roman Pichler, Mike Cohn and James Sutherland.  Scrum Product Ownership: Balancing Value from the Inside Out is one of a couple of books that attempt to give pragmatic advice on the role of this pivotal and important part of the agile machinery.

Pragmatic is the operative word.  Bob sensibly applies the knowledge and thoughts of others including current sparring partners Ken Schwaber (Scrum.org) and Dean Leffingwell (SAFe).  All ideas are up for grabs it seems including his own.  He quite obviously, to me at least, doesn’t remain dogmatic to one particular point of view and applies ideas as appropriate to the context at hand.  This is a good thing, and in such a guide the reader needs to be informed of the best thinking from all points view.

Bob is candid also about previous writings shortcomings as well.  For instance, the role of Product Management is quite large and Product Ownership only deals with a portion of the activities of Product Management.  Therefore it’s important that there be symbiosis between the two roles and not a hand-off.

I also like the idea of no single wring-able neck.  The PO can be assumed to be person in the gun when things go wrong.  I also do not hold this view as it’s the team who are collectively accountable and in fact usage of the term in my opinion is an anti-pattern and indicative of something wrong in organisational culture.

And to further add to the pragmatic nature of the book, there are many practical tips.  Bob talks a lot about management of the backlog more than the a list of items.   For example, I like his 20/30/50 rule for backlog refinement.  That is the top 20% or product backlog items should be at or near a level of detail for it to be immediately pulled into a sprint when required.  Meaning work to groom these items is constantly occurring driven by the PO with expected assistance from the entire team.  And by near enough ready there are 30% left during the sprint to fine tune and make new learning as work progressing which lines up with Scrum Guide statements.

Overall, the book emphasizes the immersive and totally involved nature of the PO role.  This is backed up with concrete examples of the types of activities required for success.  From this it can be seen that it is a full time role that needs firm backing and support from management.   I’d recommend it for the reading list of upper management as well.  It’s easily read and not overly long so can be read in a few sittings.