"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
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?
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?
11/06/2013
My agile failures - Deploy to production is a finish line
Agile principle highlight that to be agile, we need to deliver valuable software to customer in continuous way. In practice, it becomes continuous delivery. And we keep forgetting about customer value.
My experience is that we focus on starting Agile transformation at Engineering/Technical teams is easiest way to do considering popularity of "agile" in software development space. But as soon as you get a team up to certain maturity level, you will be able to deliver a piece of software continuously. I were in a phase like that. And I still didn't see lots of satisfied customer faces.
So what has been wrong? There are few things that I found that we can do better:
My experience is that we focus on starting Agile transformation at Engineering/Technical teams is easiest way to do considering popularity of "agile" in software development space. But as soon as you get a team up to certain maturity level, you will be able to deliver a piece of software continuously. I were in a phase like that. And I still didn't see lots of satisfied customer faces.
So what has been wrong? There are few things that I found that we can do better:
- Didn't engage customers in story discussion and delivery (we only involve customer proxy - Product Manager in the discussion)
- Treat deploying to production as full stop, then
- Engineering is disconnected from customer; Small issues are stopping large number of customers adopting
- Project based methodology has delayed future improvement
- Support team take over communication even for MVP products
- Lack of communication between teams and engineering team after software on production
What I have done to improve the outcome:
- Setup a kanban which has "transition" as one of columns; Project/Stories will be only moved to "Party Time"/Finished/Done when it is proved to work for customers;
- With above Kanban board, we make sure improvement stories related to new projects/stories have highest priority
- Engage customer directly in "transition" stage so that customer values can be delivered in timely manner; Project can actually become "valuable" product
Some further things to be answered:
- Does "Project" stop us from doing better job?
- Without project, how will you manage budgets?
- How to engage customers more in execution/in progress stage to shorten transition stage?
If you have any suggestion, please let me know
07/06/2013
My Agile Failures - Customer Value and Failure Demand
Agile first principle: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
So first of my thought that means that we should deliver customer value
as quick as possible. As highly experienced developer and architect, a
customer value does not only include function delivered, but also
include non-functional requirements including quality, security and
others.
But with monitoring in place, it doesn't seems that our agile delivery bring more significant sales into business. So which part goes wrong. A recent read of John Seddon article bring some lights on that. In his article, he talk about failure demand - "demand caused by a failure to do something or do something right for the customer". Most of our "agile" delivery are delivering wrong thing quickly.
There are few wrong sides for things delivered:
1. Miscommunication and information lost
2. Someone else did that and that is valuable to our customers too
3. Never analysis root cause of customer business problem; So solution can't solve the most important problem
Sprint Review has been prescribed in SCRUM as part of process. But our product delivery and customer value feedback were just skipped after sprint review. And there were no continuous improvement process related to product development and provision.
What I am trying at the moment
1. I have setup Kanban to visualize whole product delivery process including MVP provisions
2. Plan to have some review meeting like sprint review. But it focuses more on product delivery to customer.
But with monitoring in place, it doesn't seems that our agile delivery bring more significant sales into business. So which part goes wrong. A recent read of John Seddon article bring some lights on that. In his article, he talk about failure demand - "demand caused by a failure to do something or do something right for the customer". Most of our "agile" delivery are delivering wrong thing quickly.
There are few wrong sides for things delivered:
1. Miscommunication and information lost
2. Someone else did that and that is valuable to our customers too
3. Never analysis root cause of customer business problem; So solution can't solve the most important problem
Sprint Review has been prescribed in SCRUM as part of process. But our product delivery and customer value feedback were just skipped after sprint review. And there were no continuous improvement process related to product development and provision.
What I am trying at the moment
1. I have setup Kanban to visualize whole product delivery process including MVP provisions
2. Plan to have some review meeting like sprint review. But it focuses more on product delivery to customer.
09/04/2013
Agile Principles
Everyone in Software Development knows about Agile Manifesto;
But I personally believe the principles are more important.
What is your thought on each of them?
But I personally believe the principles are more important.
What is your thought on each of them?
We follow these principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
16/12/2012
2013 Goals
Personal Health:
- Bicycle in average 4 hours a week
- Go to bed before 12:00PM
Family Health:
- Towards more health diets
- Schedule family traveling to increase communication and family mentality sync
. A trip South Australia
. Schedule a return trip back to China
. Schedule a trip to country side
Personal Growth:
- Join 2-3 Conference at least one focus on Lean and another one focus on trending of technology
. Joined Lean/Agile/System Thinking Camp
- A blog post a month around Agile/Lean (need some boost for this)
. Collecting topics
. Trying to catch up to make up 1 in month in average
Networking:
- Attend 2-3 Conference and start spread network (need more work)
Professional Development:
- Start to know one colleague a month out of product/support/engineering team (Started Coffee Club, it works in some way; Need to solve the problemt hat uncertainy commitment from sales teams)
- Help defining Agile culture in other departments and senior managers (Spread agile culture through the Coffee Club at the moment)
- Apply system thinking for organization changes (need more reading and study for this)
Subscribe to:
Posts (Atom)