Author Archives: Nick

Right Size First, Then Split

There is a hell of a lot going on in Agile Space on Story Splitting.  On the internet and I hear it in interviews and conversations.  It’s as if the only solution to smaller batches is to split ad infinitum.

Now don’t get me wrong, big batches are not good.  They hurt feedback mechanisms, create silos and delay delivery of value.

And there is the point, delivery of value.  Getting value to the customer is important.  Story Splitting is one way.  It doesn’t need to be the starting point.  We may be losing our focus on delivery of value by thinking about a process.  Value is not defined by the splitting of stories.

Something to consider then is to understand the nature of your work.  Are there different types of work, or another way to put it, sources of demand?  Can you use that information to help?

Maybe your team is predictable in it’s delivery.  That’s great and congratulations to you on that.  That data on delivery time can be leveraged.  If you can say we can deliver product enhancements on one product within a time frame and be confident about that say 85% of the time.  There you go – you have the makings of a Service Level Agreement or SLA.  Your customer may even be happy with that!

How can that help in sizing stories?  Well Dan Vacanti describes it in his book Actionable Agile Metrics for Predictability.  It’s called Right Sizing.  In essence it shortens the sizing conversation by asking does this work which we are about to take on fit in within our SLA.  If so then pull the work.  If not have that splitting conversation.

It’s that simple.  However, if you are experiencing problems in predictability and expanding delivery times then you’ll want to deal with those.  Dan’s book describes how Little’s Law and its components gives you ample information to help discover issues in your process.

Story Splitting is an option to start with.  You can consider others like this.  I think it will help you understand work to a higher level of fidelity.  Your customer will hopefully feel the difference as you deliver to them more meaningful increments of value from the increased understanding.  Coincidentally, you’ll also be on your way to be being better Systems and Lean Thinkers which are interesting subjects that will aid you being of best service to your customers.


What makes you Fit for Purpose?

Can someone answer this question?   Well yes, I can help.  In short it’s what you do, be that individually but mostly in a team, to ensure anyone you serve receives the service you provide in a reasonable time frame with appropriate quality.

Where does that start?

It starts with understanding who your customer is.   Taking steps to learn about the customer and what satisfies them.  There are some tools available to you to help like Customer Surveys, Customer Interviews, Customer Empathy Maps, Personas and going to see for yourself.

Somewhat lagging but still providing information about the customer and their needs ( which can and are probably changing) is a Net Fitness Score which is an alternative to Net Promoter Score.  If you are producing software you can add code to capture data about how your customers are using the application.  This is is part of a process called instrumentation that is done to computer programs.

This takes us into the area of measurement.  In addition to customer measures, a team can also use other metrics to ensure delivery is just right.  By just right, we mean that any feelings of over-burdening (muri) are minimised to ensure that a team can sustainably deliver work.

Here some measures include, service response times (cycle time) for the different types of requests a team gets.  Are we able to deliver those reliably.  By reliable we mean within the realms of probability and not exact measures.  Knowledge Work being naturally variable in nature we tend to defer to probabilities like a Service Level Agreement. 85% of the time we can deliver in 3 days as an example.

In aiming for better on-time delivery you may need to eliminate muda or wasteful activities.  You may find amplifying collaborative activities and learning new skills will help. These type of improvements stem from understanding the nature of different requests like demand (high and low periods), expectations of quality and when request are expected to be fulfilled (Cost of Delay).

Another measure is acceptable defect levels, with the aim to reduce these to a negligible level.  Defects may need to be balanced with responsiveness.  If you require greater responsiveness then Fit for Purpose may mean acceptance of higher failure load (another name for total defects).  Responsiveness may also mean less predictability and some work may have an have a wider range of delivery date performance.

If failure load is high, then addressing some level of quality can also have a bearing on on-time delivery.  In software development that means ensuring little or no technical debt.  High levels of technical debt lengthen cycle times as a team looks to deal with the complexity of software laden with technical debt.   Continually reducing and maintaining low levels of technical debt will help maintain reliable delivery.  It will also allow innovation to occur because the team is freed from the burden of low quality.

Addressing these and becoming reliable means you will have confidence to communicate service level expectations within reasonable levels of probability.  Doing this with appropriate quality will often result in plaudits to the team and reversing what may be many sources of dis-satisfaction for the customer and team a like.  Find out what makes your system of work Fit for Purpose.  Work hard on reaching that level.  Agility will be a natural result.


Webinar: Case Study Agile Testing results in DevOps Success

I recorded a webinar for CodeGenesys on a case study on Agile Testing involving my Australian Client called AgWorld.

Hopefully it conveys that quality is owned by everyone and quality starts well before a line of code is written.

Quality right through the value stream is cornerstone of DevOps success. This carries on right through the software development life cycle starting with requests and turning those into executable specification with BDD/ATDD, automation of unit and integration tests and with the aid of automation tools (Build and Deploy) to increase the delivery rate of completed software to increase the frequency of feedback lloops.

 


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.


Is the Nassi-Schneidermann Still Used

Thinking back to when I was learning programming in the 1980’s the instructors taught us about program creation by a visualization technique called Nassi-Schneidermann diagrams. Here’s a nice summary from breezetree.com.

I thought it was an excellent way to visualize program flow for a novice. It’s only needed for a short time and learners can quickly move to pseudo code. Most programmers can move beyond pseudo code as well.

Knowing the importance of visualization in the Kanban Method, I wonder if new students to programming are being taught via the Nassi-Schneidermann?

Can we use it to increase engagement with the people we are delivering software to?  I suggest we can.  I’ll leave you with this example from breezetree.com and ask can you understand the flow of the program?

nassi-shneiderman-diagram

 


Agile before it was cool

This is a page from a great book by an important author in the software development field, Tim Gilb, called Principles Of Software Engineering Management.  It came out in 1988.

20160119_202722

The language is reminiscent of the time and the practices that were in place then, but it was ground breaking in that it talks a lot about what we call Agile Values today.  In fact Tom Gilb invented his ‘Agile’ and ‘Iterative’ EVO methodology in the early 1970s.  It’s mentioned in the book as well.  This was well before Agile became what it is today – a business.   Tom was so ahead of his time, I remember back then that Iterative development was never ever mentioned in schools and in the workplace.

And therefore, I think this Bill of Rights still holds relevancy.  I made the challenge on twitter and some thought point 9 was not relevant, rather a relic of the past.  I tend to think it’s misinterpreted in the twitter response.  Here’s the link to the twitter feed and a snap shot below.

 

There is power in this for the worker here, even on performance.  Leaders can use this to create an ethos of transparency.  Looking back to look forward.


Best Posts for 2015

Not as many posts as the previous year with just 36.  However the blog received more views that the previous year.

The Most Popular

Again, my review of L.David Marquet’s book Turn the Ship Around was the most popular.  Seems like a popular book and the author regularly recommends looking it up.   My series on Personal Kanban has trended well again but a long way back in the field.  The blog on Realizing the Power of Agile Testing was initially popular.

Blog stats 2015

My Favourites

2015’s favourites includes the case study on Agile Testing entitled Realizing the Power of Agile Testing.  It was initially very popular through some sharing on Twitter and Linked In.  Not a popular subject for web key word search it seems so it’s popularity was fleeting.  The message is still powerful.

A blog added at the end of the year and received a number of hits (96 in two weeks – not bad considering overall hits to the blog) was a tip for those doing scrum to add workflow to their task boards.  It’s called Avoid the Workflow Masquerade.  I expect that to continue to be popular this year.

The Controversial Ones

This item on making the best of your abilities is controversial because it challenges some poor behaviours which are for the most part condoned but ultimately reduce the effectiveness of teams and the ability to hire new people.

The Unloved Ones

This one would also be termed controversial.  It’s a rant about the bad behaviours at work.  It has some tips at the end though.  Didn’t get much love due to the nature of the article I suspect.

Looking forward to a new year of blogging in 2015.

Happy New Year – All the Best – Nick