Monthly Archives: May 2014

Too Busy?

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.

Any comments?

toobusy_harkanforss toobusystonage
knight_machinegun_toobusy
Click on an image to see a higher resolution version
Advertisements

Agile and Efficient Requirements Workshop Tips

Agile requirements gathering is an ongoing task that occurs throughout the build of an application or project.  We never, ever, generate the full requirements up front as this assumes we have learnt everything.  This is hardly ever the case as we learn as we go as we get better at the domain we are working in and the feedback we receive from users.  It also means we don’t waste time on ideas that may not be needed. This great article gives more reasons as well. We must be careful to also focus on goals and avoid creating solutions (e.g. the system shall…) as we gather requirements.

One of the tools available to a team is the Requirements Gathering Workshop.  This is a focused and time-boxed activity to increase our learning and understanding of the domain.  Gojko Adžić has written about this quite extensively.  Other ideas like Deliberate Discovery and Feature Injection assist as well.  But for workshops Gojko provides solid reasoning.

I’ve summarized his thoughts on requirements workshops from his book Bridging the Communication Gap.  He builds on this in his subsequent book Specification by Example.  If you buy Specification by Example you can get Bridging the Communication Gap for free from Gojko.  This is a summary so don’t expect a full explanation here.  Hopefully you still find similarity in your own experiences and a reason to seek out Gojko’s pragmatic and useful books.

He also gives great training (from what I hear/read from Perth Western Australia – he’s in the UK).  I also include this in my course on Agile Testing for which this post is also a little plug for.

  • Diversity is an advantage.   Avoids GroupThink and embraces Wisdom of Crowds.  Diversity includes different roles, backgrounds and don’t forget the stakeholders.
  • Agreement should be reached within the timebox. Max 4 hours for a two week iteration.
  • Knowledge Transfer is key. It will allow suspect issues to be surfaced quicker.
  • Challenging of ideas is encouraged until agreement is reached.
  • Ok to come to a workshop with ideas – but they need to be critiqued.
  • Go to the source – avoid third parties and telephone game info.
  • Output are examples, not solutions. This will limit flow and is the wrong time to discuss solutions.
  • Examples are good, the most important output is Shared Understanding
  • Run Feedback exercises to measure understanding. Differences in feedback indicates misunderstanding exists
  • Common Language to avoid translation between business and technical jargon.  Use the language of the domain.
  • Not a Meeting and favour smaller workshops to remain focused
  • Not a Presentation – not how the system will work.
  • Open Discussion focussed on goals

Who can Facilitate – a role for a Business Analyst

Don’t have access a professional facilitator?  Got a Business Analyst?  Use them.  The role business analysis is transformed in an agile team.  No need to fear as a BA can provide constant and valued input at an increased level of effectiveness than in a traditional process.

The role is transformed from ferryman of information using the lowest bandwidth communication (documents) to a facilitator using highest bandwidth communication (human communication face to face).  Developers benefit from your valued input via the facilitation during the workshop, chasing down pesky issues, chasing greater business value. Because they don’t miss the vital points and aren’t subject to ambiguity and misunderstanding as before, you’ll have time to do this.

By automating the specification into an executable specification trace-ability is improved and tracking of progress is improved as well.  Costs come down and more value is delivered quicker.  Value can be created elsewhere (see the Pareto chart here).

Your confidence goes up and stress levels come down and rituals like CYAM are removed.

The role of the BA has a lot to offer in an Agile setting!  Here’s a great drawing from Lynne Cazaly summarizing the role of a BA in a talk given by Bernd Schiffer and Chris Chan.

Role of BA


Being Agile with Legacy Applications

A common question is how to deal with legacy applications.  There is a lot of confusion on how to deal with legacy with most people confused on what to actually do.  They end up maintaining and patching the old code eventually to the point where a full rewrite is ordered and the cycle then repeats.

Then the rewrite proceeds to do a one for one replication of features in a new architecture but then degeneration starts again any after the new version  is released in one fell swoop after many months or years of development.  This also fails to take into account whether the legacy features are actually needed and therefore waste is introduced during the rebuild.

How about if you could enhance the legacy application by applying patterns that help remove the legacy code in a gradual and calculated manner.  Yes, it can be done and has been done.

Here are some sources of information you can look at:

There are other sources in the Agile space that help.  You many know of other sources directly related to the subject.

Please let me know if you know of anymore.

 


Is my startup idea failing?

A few months ago I created my landing page for my startup idea.  So far not one single notification or download.

Did I publicize it enough?  Is my next pivot to abandon it?

Here’s the direct link to the idea.


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.

 


A quote on Test Driven Development from 2003 – Sometimes you need to fail

Wow – I was searching my email for something else and in passing re-discovered this except from an email I wrote in 2003.  I still struggle with this in 2014. Here it is as is with small grammatical errors included:

“I did this last week with someone on my team at InfoHealth.  This person had not unit tested the code (properly) and there were loads of errors.  I fixed them by first writing the tests to catch the bugs and then methodically fixing them.  I finally got to a green light. Yay.

A couple of days later this person changed something and whammo the website we were working on was giving the wrong results.  This person was really having a rough time of it trying to find out what the problem was.  I offered to setup the test harness on his machine but it didn’t eventuate (he had tried himself and was unsuccessful getting it to compile).  The next two days he was away.  I logged on to his machine and got the test harnesses to run and show the first error.  I didn’t proceed to fix them though.

He then came back in.  None of the bugs had been fixed yet after a day of some fruitless bug fixing previously. I suggested him to fix the bugs through the test harness.  He ran the harness and discovered the first error and fixed it, and then the next and then the next.  After about 90 minutes and fixing 9 or 10 bugs he was done.  He comment afterwards was ‘Testing was never so much fun’

Hopefully I gained a convert to Test-Driven development.  Only after demonstrating a regression test suite it made all the difference.  This person was not on the project where we had previously done Test Driven development and I felt he was a somewhat cynical person as well who gently needed to be shown the light.

And so ends my anecdote.”

Testing is so important but we are still refining the practice.  Lately James Coplien and David Heinemeier Hansson (DHH) have been wanting to scale back unit testing (both from different angles), removing some of the pedantic nature (my words).  DHH wants to take it out a level to the integration.  They both have valid arguments.  See DHH’s article for more and this will have links to James Coplien’s ideas as well.  On May 9 2014 Kent Beck, Martin Fowler and DHH will be discussing TDD in a google hangout entitled Is TDD Dead.  It should be interesting and I’ll be tuning in.

Testing exists somewhere and we are trying to get to the sweet spot, balancing the risk mitigating advantages and the ROI on creating and maintaining them.

Edit: The second episode of the TDD occurred last Friday 16 May 2014.  DHH struggled a little with his argument the TDD creates bad design. Perhaps more like inexperienced programmers create poor designs. James Shore weighs in here.

The HeartBleed bug and GOTO Fail bug in Apple products could have been prevented by a unit testing culture and saved a lot of time and money as a result.  This article from Mike Bland explains.  I’m of the same mindset that we should not resign ourselves to an acceptance of complexity and that these things ‘just happen’.  Simple design and unit testing would have greatly mitigated these issues.

The non-unit testing culture means there are probably many other bugs waiting to be discovered.  The relatively small impost on time to do unit testing and do it well is paid back many times over.

The twitter hashtag #IsTDDDead is covering the debate, although now seems to be simmering down.

Uncle Bob Martin puts TDD in the context of Teams, paraphrasing – Good personal hygiene is good for the team.


Lean Enterprise Presentation by Barry O’Reilly and Gary O’Brien of Thoughtworks

We witnessed a short and sharp presentation on Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale by Barry O’Reilly and Gary O’Brien.  It was a bit of a plug for the new book.  Quite a good talk but I fear the audience didn’t have enough of the heavy hitters in town for it to make an impact. I mean Government Ministers, CEOs, Directors. Preaching to the converted.  Well we will all try our best at the level we are at.  The groundswell is building I hope.

Gary Barber did a great illustration of the evening’s events:

LeanEnterprise

https://www.flickr.com/photos/cannedtuna/14092742843/

The talk was essentially about bringing Lean Startup and other Agile and Lean concepts into the boardroom.  Here’s my recollection of the presentation with some opinions and interpretations, experiences interspersed and links to my other content.  Admittedly some of this new as well so I try and relate it back to what I know and maybe, hopefully, generate positive feedback to increase mine and other’s knowledge .

Getting to the Right Thing Quicker

Essentially we should be getting to the right thing quicker.  Us in the Agile space have been working in the ‘Sandwich’ where by delivery is stuck between two very thick inception and delivery phases.   The inception phase is the largest waste with much theorizing instead of experimentation and collaboration and top down command and control.  What we need is a new organisational design – something that has been talked about on the fringes but seems to be gaining some traction.

Change the Design Means Creating Safety

So the new design needs to be adaptive and resilient.  To achieve this fear needs to be driven out and an environment of safety should be created.  This idea of safety is gaining more and more discussion.  The Japanese called it Anzen and Josh Kerievsky has made it his next focus insofar as software delivery is concerned.   Governance changes completely.  Instead is contracts which are laden with many clauses, this calls for complete transparency and implies greater collaboration.  Less adherence to contract and process and more to the end result, that is customer value!  Customers cannot and should not value contract adherence and process driven metrics.  The example of GOV.UK is an example others are looking to.

Traditional Process is W.R.O.N.G.

So, you may not have noticed but something startling has occurred in the last 50 years.  87% of Fortune 500 companies are gone.  If this is something you find acceptable then stop reading NOW!  If your values include long lived, purposeful and humane then this is more for you.

For us in I.T. with been managed as a cost centre.  A cost engenders a mindset of cost reduction.  But the successful organisations going forward value IT as a strategic capability.  Therefore this is something used to increase competitive advantage or value creation.

Creating value needs to factor in observation and adaptation.  This looks like Demings PDCA cycle.  Most organisations don’t explicitly include Check and Act, only cycling on Plan and Do and not reacting to feedback is a coherent manner or not all.

PDCS-Lean-Enpetrise-Talk

 

Dangerous Mindsets Persist

It seems like common sense.  But the excuses are often the same.  “I’m too Busy’, ‘It’s too Complicated’.  But we can see those who reject these mindsets are succeeding.  And just to prove it we have the case study of GOV.UK, the all inclusive website for the public in the UK which began with startup principles with only a team of 6 people and is now grown organically to 600 people via proving up concepts at a small cost rather than expensive feasibility, discovery and planning phases that aren’t nimble enough or reject new information inputs.

Budgets Create Opaque Organisations

The annual budget cycle does not promote transparency.  Budgets are allocated and each group will guard them.  It’s not safe to give up your budget when you don’t need it.  Your spend it to ensure your retain your budget.

This is an instance of not providing safety.  It’s not safe to give up your budget for another area that may need it.  This creates the gaming organisation and management by accountancy rather than the ultimate goal of customer value.  By  creating safety this begets transparency and this will eliminate duplication.  Therefore reallocation of capital can occur and therefore the most efficient use of that capital.

Safety Creates Positive Behaviour

Creating openness and transparency results in extraordinary changes in behaviour.  Instead of hoarding allocated budget, the unnamed company mentioned as an example during the talk, had a director return $18 million back to be reallocated to the next most important item on the backlog.

Agile and Lean Tools Operate at the Board Level

Directors and/or members of the board are speaking more often generating feedback and sharing learning’s.  They apply rapid estimation techniques based on relative sizing (Planning Poker anyone) to size up and value capabilities they think they need.  They have built up an intimate understanding of their teams abilities over a period of months to be able to spend relative small amounts of time on this task.

The progression to actually trying to development these capabilities.  This requires some more agility.  Without going into too much detail or specifics the following formula is utilized.  These terms should be familiar to those will versed in Agile and Lean:

WSJF = (Customer Value + Cost of Delay + Risk of Opportunity) / Job Size

WSJF is the weighted shortest job first.  A simple way to prioritize.  Job Size is the relative measure and is not time based (see my previous article).   The Job Size cannot be so large that important feedback cannot be gained.  We need to get feedback to be able to pivot and cancel the project at minimal cost or continue on, reacting to that feedback and continue to fund and build that capability.

We should be able to ask the question – ship or not.  This is a key agile concept captured through several abbreviations like MVP, MUST, MMF, PSI.  The graph below reminds me of the stacked pareto that Jeff Sutherland talks about in mentioned in my Product Owner article.  Kind a like that one better.

LeanValue

 

Some Nuts and Bolts

  • Avoid the CAPEX/OPEX dichotomy to drive decision making.  It’s all directed to customer value so it’s all the same. (admittedly this may be an oversimplification, but I found this article from Dan Greening interesting)
  • Stop Pushing as this generates more cost.  Pull systems work best and don’t overload.
  • Use the true meaning of earned value.  Value delivered to the customer.
  • Value is a Yes/No question.  It’s unequivocal.
  • But value is a qualitative measure as well.  Develop new metrics.  A great example is the Love Metric.  How much do the customers love the product.
  • Accept small losses to get the big win
  • Validate with Evidence!
  • Create Long Lived Teams, Cross Pollinate Knowledge – This can halve the Cost of Delivery!
  • Leave time to innovate. It was described as horizon 3 in the presentation. I just call it a component of slack which I wrote about here.

More Big Ticket Takeaways – Go and See

Ignore the meetings just and go and see for yourself.    This means eliminating the hierarchy, a transformation from a Hierarchy Aligned organisation to a Value Aligned organisation.

See what is really happening and make it visible.  Map your value stream and see what the components of delivery of a product contains.

Measure the value and have a systems approach to improvement.  Measurements occur at team levels and should factor in the entire system not just your sphere of influence. That is eliminating the gaming culture.

Factor in time for innovation.

And as GOV.UK shows – start small!