26/09/2013

Three Maturity Levels for Software Delivey

I believe that there are three maturity for software delivery.

Level One is delivering software as specification;

Level Two is delivering solution to solve business problem;

Level Three is  delivering solution to deliver customer value;

To be agile, you need to be at level 3


20/08/2013

Transition in Agile Project Life Cycle

After some reading of "Lean  Startup" and "Scaled Agile Framework", I start to think about to add "Transition" as part of project life cycle into our projects. The problems that we have been experiencing are:


  • There is no feedback after projects delivered into production environment
  • Lots of team members treating deploying into production as end of life cycle
  • We have lots of features deployed into some of server for early access purpose, but there is no feedback loop into development team
  • Difference between business values expected to delivered and business values gained, no learning gain from that
From 2 months ago, I have setup portfolio board which outline projects and BAU items in project as a business and start to have in-transition as part of process. What is most important factor we are looking for
  • Mindset that project is only finished when stakeholders/customers gain values from it
  • Build learning culture across business about what we have failed and been succeeded 
  • Extend learning culture from Engineering team to other business departments
  • Early access program which bring a safe-net to delivery team 
  • Help support team and operation team preparing for production 

We are still working towards a better transition period. But most of feedback is positive and we will continue and make it better. There are few things that we have done along the way with feedback
  • Build rhythm for projects in transition too like setting up catchup every week
  • Setup specific page or websites as communicate tools between customers and business when projects in transition stage
  • Dedicated communication channels while projects are in transition to make sure problems solved as soon as possible so that business values can be delivered
  • Stories discovered in transition stage is always treated as highest priority
Please note transition is different from "harden" sprint in many ways. And if you are working towards continuous delivery, you should not have "harden" sprint at all.  At the transition stage, solution is delivered what it designed to do. But it may not fulfill customers' expectation fully or the solutions is deployed to test hypothesis. From transition, we need to learn something and business will grow with the stuff learn from it. 

08/08/2013

Stakeholders and Business People in Your Project/Product Delivery

It has been amazing Agile journey since 2006 when I applied some general agile practice in my own business. And I have seen lots of advantage when business is small and innovative. And it fits with my personal believe that team output can be gain while empowering people. I had been working as owner, project manager and architecture designer at that time. It all works so perfectly because I always brought lead developer with me to talk with customer. As its nature of business, it is easy to get business people and client together with developers. 

But recent experience with SCRUM has given me headache. Product owner has been go-to person for questions related to business. Product owner decision is representative of both clients and business needs. Communication lost cost is high. And my experience has been that product owner acts as middle man in the case they are accountable for product delivered. I personally believe bring stakeholders including customers into table is one of the solution when product owner has decide priority and core requirement. 

What I am doing at the moment? There are few things: 
  1. Identify stakeholders from internal and external in project vision statement
  2. Bring stakeholders in grooming sessions to help developers understanding what customer needs
  3. Product can decide whether it is in scope or not if developer think some changes may requires huge amount of work
I have been pushing vision statement and identify stakeholders for projects. It has bring lots of value into business in which we don't such doc before. And I haven't try 2,3 yet. And planning to do soon. 

If you have some way to involve stakeholders in discussion both before development and after development, please send me or leave as comment


12/07/2013

My Agile Failures - Deliver Software Frequently without Enough Safenet

"Deliver software Frequently" becomes symbol being agile. As my previous post, I am talking about that delivery software to production is not finish line because feedback loop has not finished just with that. This post I will talk about deliver software frequently without building enough safe-net or not enough infrastructure.

Recently, I have been push software from releasing every week to several times a week. But in the same time, there was an incident happened. Of course, there are many reason behind that. There are always many reason behind an incident. But the most important lesson that I learn from that is safe-net for delivering quickly.

The basic assumption that a team should have is that if there is a failure, what we can do. How can we achieve rollback without customer notice or with minimal impact. "Fail more often" doesn't mean that you can fail more often. But it is a mindset that

. We gona to fail and we should have a way and capacity to quickly recover
. We should learn from our failure

Failure doesn't necessary a system failure, it can be that metrics shows that business hypothesis failed.

And I personally found "Post Mortem" is a good way keep us learning from failure in real time. Dont let similar bad things happen more than three times.

What is your failure experience with delivering software more often?

26/06/2013

My Agile Failures - Welcome "Changes"

"Welcome Changes" becomes one thing that product owners/managers love most in Agile .  Most of time, when you talk with new teams, product owner/managers always come and demand changes; At start of my Agile journey, I did believe that "changes" are important. We should allow "any" changes. The outcome is output of team is unstable and feature delivered were hard to maintain. And from time to time, we missed commitments because of change required. And lots of changes doesn't bring expected business advantage. 

After years practice, I believe that there should be a line for

  • Whether a change is a new story or changes to existing story
  • Whether changes are the change which bring lots of customer advantage or it is another hypothesis from product owner/manager
And if you frequently experienced any problem related to story change becoming new story, you need to looking at what is the root cause of problem. It is very important to solve root cause of problem. Mostly, I found that lack of either functional requirement or architecture design are mostly root cause of problem. It is highly related misconception about agile doesn't require document. Agile means "communication" over "document". It does NOT mean that you don't need documentation. But from time to time, document, esp design document, are very helpful, but skipped. Although you don't need them in a very formal format. But some sketch on whiteboard and record them in somewhere will help team understand problem and find question earlier.


18/06/2013

My Agile Failures - No or Long Customer Feedback Loop

For agile journey, most of companies focus on engineering practice like TDD, BDD, Automatic Testing, and Continuous Deployment. But the everything in agile is about shorting customer feedback loop time. Without it, agile practice will mean nothing to business. It will only become purely cost side for business.

The hardest thing in Agile is about involving customer / customer proxy in every stage of development including analysis, development, UI testing and customer satisfactory survey. Without customer feedback, any decision to change or add feature to a product is gut feeling and guess. Production vision is build from experience and vision. But to build a software product can survive, it is about to build an innovative product which support ever change customer's need. 

In my agile experience, I have seen similar problems happening from time to time where there is lack of customer interaction and there is no define of success for a story/feature. If the situation continues, it will cause friction between business and development teams. 

I still in progress build such feedback loop, I am trying following ways:

1. Get customers into UAT stage
2. Setup early access environment so that customer can access newly released features
3. Setup monitoring/tracking strip for user actions
4. Involve customers and other stakeholders at grooming sessions
5. Try to change to business culture to understand importance to have customer/customer proxy in house/easier to access while product delivery process

Do you have any suggestion for this?