Why Clydesdale?
Clydesdale Software Logo

Follow Us: Twitter RSS

Go Back

Methodology Mashup

In the last post I mentioned how leaders and their influence create culture.  This post talks about the other side of the same coin, process methodology.  These two sides of the same coin, culture and process, are tightly related as certain cultures have to be present to support the process.  If the culture is such that everything has to be hammered out 100% before any work begins then agile processes may not work very well until the culture hurdle is addressed.


Each methodology has good and bad things. Many of the early methodologies were very prescriptive and as time went on have become less and less prescriptive mainly because one size does not fit all. Below is a list of items out of each methodology that have been found useful. This list of methodologies is also in the order of most prescriptive to least prescriptive.


The below outline is a proposed mashup built from different methodologies. The evolution of doing it better, depends on experimenting to find what works for different situations. Keeping this in mind the below is not a success plan but a sharing of information; it is up to you, the reader, to turn this information into knowledge and apply it to get the benefits.

Things That Make Us Go Faster


  • Vision/Business Case (aka: Project Charter): In short this is a definition of the starting point. This is a 1-3 page document that describes:
    • o The purpose/business value
    • o Vision
    • o Stakeholders
    • o who are the customers/users
    • o When
    • o Business Sponsor
  • Risk/Issue List
  • Glossary – Vocabulary used for the project.


  • Small focused teams
  • Release planning  - We often need to know “how big”. Using team input, average cycle time, average lead time as well as relative size comparisons of other projects a breadbox size can be fairly easy to come up with.  It is recommended delivering a time estimate range at this stage of a release.
  • Retrospectives
  • User Stories – While not a requirement to write product backlog items as user stories it helps to remind us how humans will be using whatever it is that we are building.
  • Frequent Demos – Get the feedback, let users drive. Feedback is the lifeline of a successful project.
  • Daily Scrum / Standup – Make sure everyone on the team knows about their teammates. This is not a status meeting but a team cohesiveness activity, the information gained from it is a side effect.
  • Release Often (i.e. Small Releases) – While this may not mean production every time (though big backlogs of items not released to production is not recommended) it is advisable to release to users often.


  • Visualize workflow – see it, know it, communicate it
  • State driven queues (e.g. backlog, ready, in progress, ready to be accepted, done)
  • Pull Based – Pull an item to work on when a person has them time instead of having it pushed onto them.
  • Limit WIP (Work in Progress/Process) – The goal is to get things done not to see how many things can get started.
  • Flow driven process – A flow driven process is about keeping things moving not about filling up every minute of everyone’s day. You will find a lot more gets done consistently in a flow driven process than a capacity driven process and there is slack in the system for change and adaption to occur.
  • Prioritization Process – In Kanban it is not imperative to have the backlog fully prioritized because a “Ready” queue can hold a small number of items. When the “Ready” queue has an opening the project stakeholders can decide which thing is next. It can be useful to keep your top five items in the backlog at the top.
  • Cycle time, Lead time and Cumulative flow are used as trailing indicators (i.e. using history of what has been done). Using Cumulative flow and a burn up algorithm current and needed run rate to deliver can be easily extrapolated.
  • Queues are used as leading indicators – The visual representation of the items moving through the queues allows for adaption of the process.
  • JIT (Just In Time) Estimation – This is where task breakdown can happen. When an item is ready to be worked on and is pulled by a “doer” then the task breakdown occurs and further detail may be gathered on the story/PBI.


  • Identify wasteful activities/artifacts. I.e. Activities that do not have a return on the investment. Identifying wasteful activities can be difficult and will require down to earth introspection with an understanding that becoming more skillful at anything requires failure and learning from those failures. When the term failure is used it can also mean not doing things as well as they could be done; while it is not classified as wrong it is a failure of not doing it better.


I did not mention XP (Extreme Programming) in the above mainly because this is from the perspective of a project/program/portfolio manager. While XP does have guidance on planning and managing I have found it to be not as practical as the above for a most situations; not to mention not every project my involve software development. I do however agree with XP practices (for software projects) which are applied by the “doer” team and guidance from a development manager/lead.


Out of all the above list the biggest area that can leverage tooling is the Kanban section. The rest of the bullet points can be put into any tooling solution and many of them are human driven.


LeanKit does Kanban very well. Many thanks to Brian Button for pointing me to it. It supports easy manipulation of queues, WIP limit, swim lanes and policies. The ability to build hierarchies of boards is paramount for portfolio management. LeanKit’s portfolio management is interactive with drill downs to different boards, user stories/pbi’s and tasks.


Portfolio Management Overview:



A feature pointed out in the above video which is really use full is having a team board which may have items on it for many different projects. This happens so often on projects with supporting groups like operations.


This software package does supply cycle/lead time statistics as well as cumulative flow which are important for management a project. LeanKit also has a burn up which can be added to the Cumulative flow diagram to show the current burn rate, the rate required to complete what is in the backlog and the rate required to fill the gap between these two.


LeanKit is considerably cheaper than other options that provide this level of project and portfolio management.

Facebook Twitter DZone It! Digg It! StumbleUpon Technorati Del.icio.us NewsVine Reddit Blinklist Add diigo bookmark