Lean, Agile and Systems Thinking (a.k.a LAST) conference is a popular conference for Agilists in Melbourne. The conference is on 2nd Aug at SwinBurne University.
I will be speaking about my favorite topic : Does Agile help in building Innovative products ?. Check out more details about this conference here
If you are in Melbourne, don’t miss the opportunity to attend this event.
Here is the complexity theory article published on Techwell. This is at 30,000 Ft Level.
Most of our view about the world is based on cause and effect, which in turn is a linear way of thinking. However, the world works in a non-linear fashion with multiple agents acting in parallel. System thinking addresses this non-linearity by considering different parts of the system, their relationships with one another, and the entire system itself to solve a problem or create a future state. Some of the tenets include holism and reductionism.
The complexity theory, based on the premise of non-linearity, is the study of complex systems. Complex science embraces life as unpredictable, adaptable, and evolving. The key difference to systems thinking is that the complexity theory tends to solve a problem or build the future state with the assumption of uncertainty. Patterns and abstractions are used to understand complex systems.
Another key concept discussed focused on innovation. Chaos and randomness are the foundations for all innovations. It is proven that a detailed plan with a highly structured process won’t help in building a radical, innovative product.
Constraints emerge from the system to manage chaos and randomness, and the right level of constraint leads to self-organization. However, an over- or under-constrained system is not good for agility. There seems to be myth for agile teams regarding self-organization. Many professionals believe that just allowing the team to function on its own will lead to self-organization. In reality this is partially true; the leaders need to guide and ensure that there is the appropriate level of constraint emerging from the system.
and remaining part of this article is available here
The maturity of the company depends on trust and courage of employees. If the company is still using anonymous surveys to collect 360 degrees feedback, isn’t it a reflection of lack of trust and courage ?
Do you know any organization who gathers 360 degrees feedback in person ?
Here is one of my guest post on Zephyr : Evaluating Testers: Past and Present
Just a gist of the article is below,
Software testing has come a long way since 1960’s from debugging to defects prevention oriented approaches. However, one thing that hasn’t changed much is the way the testers are evaluated. Let us look at the history and patterns of different evaluation techniques.
Let us being with the waterfall era. It was very clear that testers job was to catch all the defects introduced during the development stage. Testers had pretty much no options other than keep showing different metrics to prove their existence.
…………….and the complete article is available here
Image courtesy of ddpavumba / FreeDigitalPhotos.net
I recently came across the the Oath of Non-Allegiance. Now we have different parties pulling the software industry in different directions. Some of them include, Scrum, Kanban, Lean, ScrumBan, etc.
Each party is willing to bet that their practices will help in Nirvana forgetting the real customer. Even though Oath of Non-allegiance is around from some time, I came across this recently. This non-allegiance accurately reflects some of my thoughts. We shouldn’t get carried away with the methods but do what is beneficial for the customer. At the end of the day, the customer and the business doesn’t care the tool we have used, they care about their experience, bottom lines, quality and the value.
Here is the oath of non-allegiance
I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation. (See http://alistair.cockburn.us)
I added this to my blog as well.
Recently I authored an article for Cutter about the Agile Maturity assessments. This advisory article covers the following topics
1. How Agile Maturity assessments are conducted in the organizations ?
2. What are the pattern of questions ?
3. What are the maturity levels being used in the industry ?
4. Typical organizations issues impacting the assessments ?
5. How does a good Agile maturity assessment look ?
Read the entire article here
Here is the recent article about radical innovation that got published on Techwell. I am reproducing the same article below:
Have you ever imagined having a private cloud hosted from your home? If so, you should check out this article that details how to set up your own private cloud in less than ten minutes with OwnCloud. There is currently a mixed reaction to OwnCloud, but we may not be that far away from building private Facebooks and Twitters on our own terms. Revolutionary ideas and technologies like OwnCloud could potentially impact the commercial cloud storage providers.
I think radical innovation is essential for survival in this century. But no one has been able to come up with a formula or a process to build innovative products like the iPhone or Google Glass. Why is this? Because innovation is a creative endeavor and is people dependent. Steve Jobs is a classic example of a radical innovator. He had the unique ability and creativity to sense the end customers’ requirements.
In addition, Steve Jobs is one of the best product owners (PO) in the world. How many Scrum projects have POs with the ability to come up with innovative product designs like Steve? Most of the POs I have come across are glorified requirement analysts. Even the Version One Survey 2012 has confirmed that POs are the least knowledgeable about agile. With such a poor track record of product owners, sometimes I ask myself whether it is possible to build innovative products in such agile environments?
Collaboration and innovation go hand-in-hand. Agile environments are supposed to be collaborative. However, the common understanding of collaboration in a software delivery context is to help each other without causing friction. If someone in the team is challenging ideas, he immediately is branded as non-collaborative, which is wrong. To be innovative, the team must understand the concept of collaboration and especially these three types.
The job market is another area that is impacted by innovation. Recently, I heard about this innovative 3D-house-construction printer. As I read this, I was wondering what potential impact this printer might have on the construction industry. Can this printer build the entire house on its own with little help? What will happen to the construction workers’ jobs? I realize that it is critical for employees and workers from all industries to build T-Shaped skills for sustainability.
I’ll leave you with this: Can an innovative product be built by applying Scrum or XP in your current project? What is hindering innovation in agile projects?
photo credit: Håkan Dahlström via photopin cc
Techwell, the popular Agile Magazine published my curated article.It is accessible from here as well.
I was shocked to read the news in Australia that constant delays at the Brisbane Airport cost airlines $75 million last year. It looks like the closure of one of the runways resulted in a bottleneck, which in turn led to scheduling issues at the busy airport.
Consider the fact that in lean terminology anything that is not adding value is considered waste, also known as Muda in Japanese. Now ask yourself the following questions: Is there a possibility that the $75 million cost to the airlines will result in higher airfare for passengers? Is it fair for passengers to pay more for a ticket when they are not getting any value? This hefty cost is not adding any value to the airlines or to the passengers.
As a software delivery coach, I see a lot of examples of waste in every step of software development. If you are unfamiliar with the concept of development waste, Craig Larman and Bas Vodde have written an article, titled “Lean Primer,” which is a good place to start. Additionally, the following YouTube video provides an overview of different kinds of wastes.
https://www.youtube.com/watch?v=mAYMcSUDcX0
Many lean practitioners use a concept known as “value stream mapping” as the first step in identifying wastes. Over at the website System Agility, the authors detail some creative games for teams to play in order to both identify and deal with the software garbage.
However, there are some unavoidable wastes that we can never remove. To counter this, many companies are using the concept of “Lean Six Sigma” to deliver a high-quality product. This video provides a nice introduction to Lean Six Sigma.
https://www.youtube.com/watch?v=5xuo5Dv7iWA
Due to Lean Six Sigma’s potential to increase cost savings, there is currently a huge demand for lean consultants worldwide. Unfortunately, getting lean consultants and setting a goal for them may not be sufficient.
Several companies have burnt their fingers while trying the above approach. The following article shows several examples that highlight the attention needed during a company’s lean implementation; some professionals believe that Six Sigma killed innovation at the 3M Company.
To conclude, let me ask you this: What wastes have you seen in your company and what did you do to avoid wastes?
photo credit: mugley via photopin cc
The key members from the technology group are waiting to hear about the new project that the director is going to announce. The meeting is about to begin, and the room is filled with silence. They know that the project has something to do with Java, Oracle, and the cloud. The director starts explaining the importance of this strategic project and delivering it on time to the customer.
Read the complete article on Cutter
This article was published on Techwell, the place to go for what is happening now in software development.
The daily standup meeting is a critical element of scrum teams. Its simplicity and benefits have even attracted the attention of practitioners of waterfall development.
The term “daily standup” originated from Extreme Programming (XP) while the term “daily scrum meeting” goes back to Scrum, of course. One should note that both XP and Scrum derived the concepts of daily meetings from software pioneer Jim Coplien and his paper on the Quattro Pro spreadsheet program.
In the simplest sense, a daily standup meeting is accomplished by having team members stand around in a circle with each person answering a few questions. But wait, life is not as simple as it sounds, and there are certain rules to be followed during these meetings. The rules cover the team’s time commitments, location of the meeting, and the meeting’s overall rigor, all of which make up the secret sauce for success.
Holding a standup meeting in a collocated environment is simple compared to holding a meeting with distributed teams, in which you need to be cognizant of time zone differences and language barriers. The use of tools—teleconferencing technology, webcams, and instant message software—can help you deal with remote teams. For more help on that front, you can read the Practical Guide to Distributed Scrum, which provides an overview of different tools and their associated pros and cons.
Most people recommend holding the meetings in the morning, keeping in mind what time the last team member arrives for the event. For some, noon seems to work as well.
As agile coach Rachel Davies explains, scrum meetings are not only about sharing yesterday’s work, but they are designed to help team members plan for the day and look to the future. If you’re working in a distributed environment, you might find help in this guide by Rally, which discusses fine tuning your meetings.
Keep in mind that there are several ways that daily scrum meetings can result in trouble for your project. For example, team members might stop attending the meetings or they could even complain that the meetings do not add any value or are a waste of time. The worst is when people make this a status update meeting.
There are several ways to fix these troublesome issues, including reinforcing the values and principles behind the meetings. Also, remember that command-and-control management issues might lead to many people-related problems, and you’ll need to address those issues if they apply to you.
Finally, if you still are having issues with standup meetings, Jason Yip, a principal consultant at ThoughtWorks, recommends a few good tips, like rotating the facilitators, breaking too much eye contact, and using improvement boards.
Following article got published on Zephyr recently.
During the waterfall era, at the end of development, the completed code was thrown at testers who in turn would identify defects. These defects would get registered onto a tracking tool. In response to these defects, the developers would swarm around them and fix all of them for the next one week. This process used to continue until the QA team signs of on all the defects.
Now with the popularity of the Agile, Lean and Continuous Deployment, the developers are required to be more vigilant while coding. They are recommended to follow practices like TDD, ATDD to improve the code quality, reduce defects among other benefits. Since these practices are supposed to reduce the burden on testers, a lot of people are questioning the need for dedicated testers in the software development.
In this article, I will address questions around the need for testers, the value they bring in, and their role in the context of Lean and Agile.
Why do we need to build the quality in?
Let me begin with the Lean Principle #2, Building Quality In. Before jumping to solution mode, let us understand the ways the quality issues crop up and the cost associated with it. Quality issues originate at the beginning of the project and the top 3 reasons could be grouped into:
Irrespective of whether the mistake is by the customer or the developer, there is an effort involved in testing and rewriting the code. As per the 1:10:100 rule, the failure to identify the defect upfront could cost a fortune to the company.
Solving the quality issues:
First issue mentioned above could be solved by the development teams building the prototype and showcasing to the customer even before touching the code. Second and third issues could be solved by practices like TDD and ATDD.
If developers and customers work closely, ensure to fill the gaps and write quality code, can we still delivery a quality product without testers ?
In recent days, some of the lean startup companies have tried customer testing and crowdsourcing the testing without involving the testers. However, it is still not proven if this is the right model. A lot of people also agree that even the most experienced developers make mistake. The developers come with a specialized technical background and they won’t have the same eye as a tester. They are good at unit level testing, and they cannot effectively do the integration/system level testing. This is not something which could be improved by automating the tests.
Role of tester in Agile, Lean environment:
Many teams have tried building products just with developer testing and have got bitten badly as well. As one could see from this discussion, people have reverted back to include testers.
There is no doubt now that dedicated testers are needed in all projects. We still need testers to provide a neutral eye and their specialized skills to improve the quality. In fact, testers have now more empowering role to play than before.
To conclude:
Image courtesy of ponsulak / FreeDigitalPhotos.net
In today's rapidly changing business environment, innovation is key for survival. Companies may become obsolete in no time in the absence of new and innovative products. A classic example of this phenomenon is the demise of Kodak. At the same time, companies like Apple and Google have not only contributed toward building innovative products but at the same time made their investors many times richer.
Check this complete article out on Cutter
Following article got published on Techwell
All of you have probably heard the news involving the recent ban on larger soda sizes in New York and the subsequent un-banning. There are people who are arguing against the soda size ban, and they are challenging government not to micro-manage their lives. On the other hand, there are people with views who vouch that this ban would help improve the health of overall society as well as reduce the tax burden.
These conflicts in thinking that occur in societies in which a group of people resist an unpopular decision are nothing new and not restricted to large societies at all. We see these things in our day-to-day life—even in our work places.
Have you come across situations where project teams have resisted changes suggested by their leader? To add another twist, what if the teams were self-organizing, as in the agile world?
Self-organizing teams are supposed to have clear goals and manage their own priorities to achieve them. This does not mean that they are leaderless. Let me clarify at the outset that self-organizing teams have leaders and someone to monitor and support them.
As author and developer Jim Highsmith says, they need light-touch leadership. Leadership needs to step in if the self-organizing team are treading in the wrong direction, thus moving away from the goal.
I heard a story from the trenches about a particular self-organizing team going through this journey. This new agile team felt it was a waste of time to do Scrum rituals and collectively decided to skip the daily stand ups and retrospectives.
As expected, the ScrumMaster stepped in, did the root-cause analysis, and found no reason to skip the rituals. The ScrumMaster then tried coaching the team about the importance of rituals and why team members should not ignore them.
However, the team members decided to escalate further to senior management to get support for their cause. Let’s say you are part of senior management. Would you be supporting the ScrumMaster or the team? I am sure most people would agree to support the ScrumMaster since the daily stands ups and retrospectives help agile projects, teams, and their own bottom-line in the long run.
However, what if management supported the team's skipping the rituals? Supporting the ScrumMaster would have caused more agitation by the team, which would result in a loss of team morale. Tying this story about self organization back to the New York soda ban, I see that Mayor Michael Bloomberg (ScrumMaster) had all the good intentions to save lives by bringing this change; however, he didn’t get support from the citizens (self-organized teams).
How would a ScrumMaster bring about change in the above situation? What kind of management practice could help team members change their minds?
Here is an article about Agile coaching published on Techwell: http://www.techwell.com/2013/03/what-true-agile-coach
A few years ago, I had the opportunity to work closely with Craig Larman. I consider Craig not only a great coach but a teacher and facilitator. Craig has gone through the rigorous process of becoming a professional coach. However, most ScrumMasters and agile coaches are not so lucky. They are either “promoted” by their organizations or sometimes self-promoted; this results in coaches that lack skills.
Most of the Scrum and agile certifications available are given to professionals who can demonstrate that they are able to practice daily standups, anchor showcases, and facilitate retrospectives. Obtaining these certifications typically does not require that a person learn the fundamental differences between coaching, facilitation, and mentoring. This lack of understanding is reducing the quality of coaching to our customers.
So, what defines coaching and facilitation?
I like these simple definitions from Changeworks:
Coaching is about helping you uncover and develop the skills, attributes, and talents you already have. The main coaching tool I use is listening and questioning, you already have the answers; we just need to ask the right questions!
Facilitation has its origins in the French word ‘facile’ = easy. It’s about making the process of a team or group coming together to achieve an outcome as easy as possible.
As you can see, coaching requires people to be involved in the project’s process more deeply; they need to have real skin in the game. A project’s outcome is driven by coaches, and many decisions are led by coaches.
Keep in mind, however, that while coaches can suggest a new process or change an existing one, the role of a facilitator is important. The facilitator engages the team in the right conversation, and from that the team makes their decisions.
A good definition and analogy about facilitation can be found on this LinkedIn discussion post:
Imagine that you are a midwife; you are assisting at someone's birth. Do good without show or fuss. Facilitate what is happening rather than what you think ought to be happening. If you must take the lead, lead so that the mother is helped, yet still free and in charge.
When the baby is born, the mother will rightly say: "It's my baby!"
Coaching involves a combination of facilitation, mentoring, coaching, and training as well. An agile coach might facilitate a daily standup, retrospective, and a showcase on one day; the next day, he might get involved in strategically coaching the leadership team by suggesting changes, identifying the resistance areas, and finding solutions.
Remember that new members need training as well. A long-term coaching plan needs to focus on relationship building, and that includes mentoring.
Now tell me—do you have opportunity to do real coaching or are you just facilitating a few workshops in the guise of coaching?
Image courtesy FreeDigitalPhotos.net
Republishing my Techwell article. This article can be read on Techwell as well : http://goo.gl/ujpva
The Boeing 787 Dreamliner’sgrounding issue is currently the talk of the town. Steve Denning’s article onForbes presents an interesting look at the news. The only problem with the article is that it only emphasizes one subject—offshoring—rather than addressing other issues in a holistic way.
I have been working on large, complex software projects in a distributed model for a long time. Over my career, I have come to realize that the issues plaguing product development—whether hardware- or software-related—are pretty much similar in nature. Most of the time, the issues are related to poor planning, estimation, and quality checks. At the end of the day, the Boeing 787 is a product; it may not be a software product, but it is a hardware one.
If you take a look at the list of issues that the 787s have encountered, you will find classic project management and quality errors.
Let me begin with the budget and delay issues. The first planes were delivered to Nippon Airways in 2011, years late and billions of dollars over budget. Surprise, surprise! Isn’t this a classic project planning and estimation issue? It has been proven through the ages that project managers should keep the Cone of Uncertainty (COU) in mind while planning. Quoting the COU link:
Estimates created at initial concept time can be inaccurate by a factor of 4 times on the high side, or 4 times on the low side. That means the total estimate range is a staggering 16 times at the time of initial concept! And believe it or not, that’s a best-case scenario.
Boeing should have taken the COU even more seriously during planning because of the new radical technology that the company wanted to implement on the Dreamliner.
Another issue that affected the 787 was an integration issue. As the Guardian reports, “The wing tips were made in Korea, the cabin lighting in Germany, cargo doors in Sweden, escape slides in New Jersey, etc. Parts never integrated properly.” The basic principle that we should integrate early and integrate often is what we agilists have been taught, and Boeing seems to have ignored it.
Boeing also suffered a poor-quality checking issue. Most of the time, quality is ignored due to time pressures. According to the Guardian, Boeing was able to get a waiver for the size, quantity, and manner of use for its lithium-ion batteries, which were not tested properly.
To conclude, I see that Boeing’s issues have less to do with a distributed way of working or offshoring and more to do with project development issues.
Do you think that Boeing has ignored some fundamental principles of product development?
In my earlier post, I had raised a question, which one of the black circles in the pictures were bigger ?
Most people think it is the left one but the answer is, both are of same size.
The reason why people get illusioned to think the left circle is because of the way humans think. We always compare two similar things while making decisions. In the above scenario, each of the center circles are compared with the surrounding circles. The center circle on the left is compared with the surrounding small circles, and similarly the right center circle is compared with surrounding bigger ones.
The relativity in decision making says that
If I visit a TV shop and there is only one TV, say 20 inch with a price tag of 500$. It is rare that I make a buying a decision as I don’t have anything to compare.
However, if the shop keeper keeps a decoy TV, say 40 inch with a price tag of 600$, then there are more chances that you make a decision, most probably towards buying 40 inch TV. Isn’t this a great idea for the shop keeper to push sales of 40 inch TVs by keeping decoy TVs around it ?
Coming to the Agile world, now you know, why relative estimation is a natural way for the teams to do estimation.
As one can see there are two black circles in the pictures below, which one of them is bigger, left or right one ? Try to answer without googling :-)
Here is the list of tools being used in an Agile environment as discussed in this forum. I have added some based on my previous experience as well.
(Updated on 8th Feb 2013)
Let me know if you are using any other tools, happy to add them here. Above picture is a screen shot from my excel and feel free to Google it around to get more details about each of them, or Drop me an email and happy to share more details about the same.
This article below I wrote got recently published on Techwell.
Nearly 52 percent of agile projects are following Scrum or some variant, according to VersionOne’s state of agile development survey. I’m sure that the dollar value of this percent of Scrum projects would run into billions, if not trillions, of dollars. With so many business people betting their money on Scrum, my question to you is “Do organizations have the right set of people lined up to deliver these projects using Scrum?”
A detailed analysis of the roles and responsibilities of an agile project clearly states that the project owner (PO) is responsible for the return on investment (ROI) of the project in addition to being a backlog owner. With POs taking on such an important role on their shoulders, are they really skilled and empowered to do their jobs?
My own personal experience working on several Scrum projects says that POs are used more than anything else for defining, prioritizing, and maintaining the backlog. It’s more of a transactional role between the PO and the team. Many product owners don’t even know the business value of the requirements.
In typical Scrum projects, the business sponsors allocate the budget and share their vision with an experienced domain expert—the product owner. This domain expert in turn takes help from so called “business analysts” to write the epics and user stories that are shared with the team. The delivery teams work like horses as they churn out code and demo at the end of each Sprint.
I don’t see how the traditional way that Scrum projects are being implemented would produce any ROI to the business in the long run. Delivering ROI depends on more than just delivering the software code and deploying it to production with zero defects. In my view, the success lies in the end customers actually using the product effectively and buying or using more of it.
Some people recommend forming a product owner team that includes business analysts and a marketing and sales team as well. However, I don’t think this is going to solve the ROI problem defined above. I am getting more questions than answers.
Will the world change and will POs be empowered to really drive ROI? Should we separate the ROI responsibilities from the product owner and call them “backlog managers?” Maybe we should look at redefining Scrum roles.
Check out the Agile Dev Practices Conference in Potsdam by Berlin. The early bird ends on January 31st.
