Building quality in – Do we need testers ?

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:

1. Customer giving a wrong requirement and realizing it at a later stage
2. The developer writing wrong code due to misunderstanding of requirement
3. Developer understood requirement but coded a wrong logic

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:

• Testers look at preventing defects and not just identifying them in the end
• They get involved in the beginning of the project working closely with the product owners(PO) and developers.  They ask right questions about requirements and in turn making every get clarity on the requirements
• They write acceptance tests, they do smoke tests and exploratory testing
• They work as a support structure for the development team in ensuring smooth delivery of the project.
• They think beyond just testing and embrace tasks that help the team in smooth deployment to production

Image courtesy of ponsulak / FreeDigitalPhotos.net

Does Agile help or kill innovation ?

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

Self Organizing teams and New York soda ban

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?

photo credit: Profound Whatever via photopin cc

Who is a true Agile coach ?

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

What can Boeing learn from Agile methods ?

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?

Which circle is Bigger ? Relativity in decision making

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

• People assign value to things by comparing one thing to another. People do not possess an innate value meter that determines absolute value.
• People are constantly comparing and contrasting physical things, people, experiences, and ephemeral things such as emotions, attitudes, and points of view.

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.

Which circle is bigger ?

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 :-)

Day to day tools used in Agile projects

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.

Should we revisit Scrum’s Product Owner Role ?

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.

photo credit: laverrue via photopin cc

Agile Dev Practices Conference - March 4–7, 2013

Check out the  Agile Dev Practices Conference  in Potsdam by Berlin.   The early bird ends on January 31^st. 

Technorati Tags: conference,AgileConference

7 Key practices to follow in maintenance projects

One of my earlier articles got republished again on DZone this week and am reposting it below. Check out this article on DZone as well.

In many Agile training programs and conferences, a common question that gets raised is, does Agile/Scrum work in maintenance projects?
I always say "YES" and the team needs to tweak or invent the practices to suit their needs.
Maintenance projects could be enhancement projects OR pure defect fixing projects.
Enhancement projects involve new set of developments over existing one. Since the developers get a new set of requirements at the end of each iteration, one can apply the standard set of Scrum practices with little or no modification.
Defect Fixing projects involve fixing defects on closed or current projects not in development. Sometimes these projects are boring, especially if a new team has been hired for defect fixing purposes only. The customer sends a set of defects on a daily basis or weekly basis with a deadline to deliver. The development team needs to fix them ASAP and send the patch for further testing.


While coaching one of such a defect fixing projects, I found that the following Scrum practices can be applied without much modification:
1. Daily Scrum meetings
2. A Scrum of Scrum
3. Modeling days while solving complex defects
4. Information radiators displaying InProgress, completed, reopened, closed defects and other information
5. Usage of Wiki for collaborating with the customer
6. Requirement workshop while understanding complex defects
7. Review and Retrospective
A common problem that I have found in defect fixing projects is setting the iteration length. Especially if the defects are given on a day to day basis without prior knowledge of what you are going to get, it makes the life of the development team bit difficult.
This can be solved by collaborating with the customer and coming up with a plan to have 1 or 2 weeks of iteration length.

photo credit: contemplative imaging via photopin cc

The 4 ingredients of building Hyper Productive teams

The complete article of my guest post on Zephyr  is available below:

It is every leader’s dream to build hyper productive teams (Hype Team). This topic not only attracts a lot of attention but at the same time leads to a lot of debate as explained in the following paragraphs. I have worked as a team member as well as a leader on several different projects in different geographies. Irrespective of the cultural background of teams, domain or technology being used, my own personal experiences of building hyper productive teams concur with several research papers.

What are Hyper productive or high performance teams?

Let me tell you that there is no formula to specify a team as Hype Team without comparing it to another team. The measure of productivity is always contextual. Wikipedia defines a Hype team as: A group of people with specific roles and complementary talents and skills, aligned with and committed to a common purpose, who consistently show high levels of collaboration and innovation, that produce superior results.

The most popular example of building hyper productive teams in the Scrum world comes from Jeff’s paper on Shock Therapy – boot strap on Hyper productive teams. Jeff defines a Hype Team as follows: We define Hyper-Productivity here at 400% higher velocity than average waterfall team velocity with correspondingly higher quality. The best Scrum teams in the world average 75% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience.”

Even though not everyone agrees with the jeff’s definition, my own experience says it is possible to build a passionate, highly energetic, self-organized team by using the following ingredients.

Ingredient 1: Identify a good leader

So far no one has been able to articulate a step by step approach to building Hype Teams. But many have been in successful in capturing the different ingredients needed to build one.  However, I strongly believe that hiring or having a good leader is the first step in building the Hype teams.  Psychology Today provides some good tips in hiring leaders.

Indicators for identifying leadership:

• Does the person help the team become more effective at making decisions quickly and reaching a working consensus?
• Does this person foster effective collaboration across a team made up of several experts?
• Does this person impose discipline on themself and their team to prepare and act with the professionalism?

Ingredient 2: Common goal and shared vision

All research available on the topic of building Hype teams agree on one thing, having a common goal with a clear vision. Building a shared vision is context dependent. In the Agile world, this could include having clarity on the backlog items, common agreement on definition of ready and done checklists, common understanding of what defect means. Are the common high level goals clear to everyone: can individuals abandon their individual objectives and metrics to respond to unfolding situations or do they wait for instruction?

Every major decision should document:

• How can we tell if this works?
• When will we know?
• What will we do if it doesn’t?

If you are struggling to understand your customer’s vision, try this popular game Remember the Future.  Reiterate and share goals/visions as often as possible. This could be done through posting the vision in a visible place, revisiting them during the showcases. The shared vision approach combined with good leadership skills would create Self organizing teams, necessary to nurture high productive teams. Self organizing is possible only if the teams respect each other.

A few questions to ask yourself in regards to building self organizing teams include:

• Is there an open and free flow of information so that teams can self-organize around problems?
• How important is for you to be in control: do you prefer inaction to mistakes in the absence of your specific instructions?
• Are the common high level goals clear to everyone: can individuals abandon their individual objectives and metrics to respond to unfolding situations or do they wait for instruction?

Ingredient 3:  Trust, Trust and Trust

Creating a safe place for the team to express their opinions and creating space for the team to fail. Building a transparent culture and following through the commitment builds trust within the team. Transparent culture can be built by making the data visible through radiators in the team rooms. Let radiators show all the risks, issues and blockers. Move away from the information refrigerator culture. Continuing to be transparent and sharing the bigger picture with the teams the time leads to people to stop working in isolation and in turn creating the foundation for systems thinking culture.  The book “How NASA Builds Mission Critical Teams” provides a detailed view of applying systems thinking concepts in building high performance teams.

I pulled an excerpt from Dr. Atul Gawande’s Failure and Resuce commencement. I think these are three skills that help teams build trust.

• Judgment: the ability to develop a point of view and to use it to make decisions in a timely fashion as dictated by the implications of unfolding events. This may require making decisions with incomplete information, and that’s a useful distinction  to remember: if you have enough information it’s a choice based on your values, if you don’t, if there are uncertainties or ambiguities, it’s a decision.

• Mastery of Teamwork: this requires effective two way communication, timely coordination, and establishing a level of trust that enables effective collaboration. It also requires alignment on goals, agreement on roles, negotiation of a common process, and a commitment to effective business relationships.

• Accepting Responsibility for Consequence of Your Choices: you can make a good decision based on all of the information you have in hand and still have a poor outcome. Sometimes a poor outcome is a possibility that can be anticipated and mitigated and sometimes it’s part of the “unknown unknowns” of a situation.

Ingredient 4: Continuous improvement

High performing teams are not built in a single day or a month. It usually takes a few months to a couple of years. Teams working on long durations need to continuously learn and evolve. This article articulates the importance of continuous learning very well.

Here is another good book Management Challenges for the 21st Century, written by Peter Drucker, address the issue of continuous improvement on the “Change Agents” chapter.

This excerpt elaborates on his core concept of organized abandonment.

For being a change leader requires the willingness and ability to change what is already being done just as much as the ability to do new and different things. It requires policies and practices that make the present create the future.

Abandon yesterday. The first step for a change leader is to free up resources that are committed to maintaining things that no longer contribute to performance and no longer produce results. Maintaining yesterday is always difficult and extremely time-consuming. Maintaining yesterday always commits the institution’s scarcest and most valuable resources–and above all, its ablest people–to non-results. Yet doing anything differently–let alone innovating–always creates unexpected difficulties. It demands leadership by people of high and proven ability. And if those people are committed to maintaining yesterday, they are simply not available to create tomorrow.

Working in distributed mode

The challenges get multiplied while working in a distributed environment. Use of effective communication tools play a key role here.  In the Agile world, the scrum of scrum meetings with key stakeholders from the multiple geographies could help in alleviating the pain a bit. I use Ideaboardz as a tool to conduct distributed retrospective, estimation using planning poker is done using Video conferencing devices.

To summarize, the recipe to build high performing team is based on the above 4 ingredients.  You miss one; the recipe is gone once and for all.

photo credit: 'PixelPlacebo' via photopin cc

Most popular posts

Thought would kick start  2013 blogging by sharing all time popular posts from my blog.

Here is the list of Top 10, ordered from most viewed at the top

1. Metrics in Agile development
2. Kanban vs Scrum Myths and Hype– Guest Post
3. The Rise and Fall of the chaos report
4. Difference between Sprint and Iteration
5. Backlog Prioritization techniques
6. Scrum + Continuous Delivery
7. Does it make sense to use MS Project in Agile Proj...
8. Scrum Meeting – Punishment by collecting $ is it t...
9. Applying Agile/Scrum practices in Maintenance proj...
10. Agile Teams to Avoid

In Bangalore - any one for Lean Cafe ?

I am in Bangalore for the next few weeks. I would be happy to meet Agile enthusiasts  and exchange ideas and thoughts around latest Agile trends, Scaled Agile Framework, Kanban or in general anything about Agile.

Pl drop me an email: venky_nk(at)yahoo(dot)com if you are interested for a  Lean cafe catch up.

Meet with Alistair Cockburn

I got an opportunity to meet with Alistair Cockburn, one of the Agile inventors.  I was fascinated with his simplicity and humbleness.

It is interesting that, last week I watched his ShuHaRi Video, which in turn inspired me to jot down few thoughts trying to predict future of Agile.

I also had an opportunity to discuss few things about the latest buzz DevOps.  

Have you applied SAFe to large projects ?

Recently, wrote this article for Techwell, and am reproducing the same here.  Complete article can be access from this link

It is not uncommon to hear about software project failures., but it's the large-scale project failures that really capture our attention—especially when the problems not only affect a company but the company's customers as well. The recent software glitches and errors that hit the Royal Bank of Scotland and Knight Capital Group damaged both organizations’ reputations and resulted in multimillion dollar losses.  

Some of the problems plaguing large-scale projects include communication and coordination errors at multiple levels as well as technology integration and infrastructure issues. Several thought leaders have made attempts in the past to alleviate the impact of these problems on the customers. Craig Larman’s recent book Scaling Lean and Agile Development is a good example. However, no one has been able to identify a silver bullet to address the issues. I doubt there is one.

Recently I came across the idea of a Scaled Agile Framework (SAFe), created by Dean Leffingwell, which is another attempt to help steer large-scale agile projects in the right direction. Synchronization of multiple touch points and early integration testing form the two key ingredients in large-scale projects, and SAFe suggest ways to solve many issues that may arise during these stages.

This screen shot provides an overview of SAFe.

 

When you see the diagram for the first time, it might look very complex. However, it carries some simple concepts in it.  Leffingwell has divided the entire framework into three broad levels: portfolio, program, and team.

Each level has been tagged with clear-cut roles, responsibilities, and artefacts to be delivered. SAFe reuses not only the Scrum framework but also the Feature Driven Development framework in some ways. This reuse ensures that the learning curve is minimal when it comes to understanding the framework.    

Even though Scrum popularized the concept of Potentially Shippable Increments (PSI), many teams ignore it. They still continue delivering islands of partially-built products in each iteration. However, SAFe enforces the good behaviour of implementing PSIs through the Agile Release Train (ART).

The ART carries all the features to deliver a PSI, just like a train carrying a cargo. At the end of each PSI, you should be able to test the application end-to-end with limited features. This concept forces the release managers, portfolio managers, architects, and developers to think about integration right from the first Iteration

Read more … here

Boss to employees: Don’t work too hard

As far as I know, the bold suggestion of recommending 40 hours working per week came from the XP community through the practice of Sustainable pace.

Even though I keep myself engaged in the Agile community quite upto date, I have hardly seen companies asking employees not to work hard or making it a policy not to work hard.



However, recently came across this article in the Australian news paper where the global CEO of WiseTech has made an unusual request to employees for maintaining work life balance by working not more than 40 hours per week !!

Here are some snippets from the news paper
If employees work more than 40 hours a week regularly, they have to talk to their manager to redress the situation.  Workplace expert and University of Adelaide law professor Andrew Stewart said the WiseTech Global approach was the first time he had heard of such a clause applying to Australian workers but he expected the provision to become more common.

He said he expected more claims to be lodged against employers for breach of health and safety laws ‘‘where you have high pressure, high-stress, long working-hours environments’’.

There was increasing evidence that productivity and effectiveness of employees ‘‘falls off dramatically when you have tired workers’’, Professor Stewart said. Recent research argued the effect on employees of working long hours was equivalent to ‘‘being drunk or high on drugs’’, he said.

‘‘Creativity is fired by emotional energy,’’ the company’s charter says. ‘‘ No life balance, no creativity at work.’’

Mr White said he had sat down with employees on about 10 occasions in the past five years and told them they spent too much time i n the office. The workforce consists of salaried, largely full-time employees who do not receive overtime.

He noted staff turnover was ‘‘extremely low’’, an unusual occurrence for an information technology company.


Isn’t this the company everyone dreams to work for ? 

How to succeed in 21st Century business ?

It has been proven beyond doubt that  Command and Control leadership style a.k.a C2 style leadership does not work.  As  Dean Anderson describes, the C2 style is based on some of the following assumptions:

• Leaders know best
• Leaders should know where they are going (goals, outcomes) and must predetermine the plan for how to get there (process)
• Controlling human behaviour and action during implementation—so there is minimal variance from the predetermined plan—is a requirement of success

The impacts of this style, as described by Dean include:

Command and control as a change leadership style destroys virtually any chance of success in nine out of ten transformational change efforts. For starters, command and control:

• Limits the engagement and commitment you must develop in your employees, and often actually promotes resistance
• Lessens your chances of creating a change process that will lead to success
• Keeps you from being able to make the real-time course corrections during implementation that are necessary for optimal results
• Minimizes attention to necessary people issues like consistent communications and emotional reactions to change

Mr Mullen, the chief executive of port and rail operator Asciano in the Australian says,

"(A) seminal shift is under way where employees do not necessarily think that the boss knows best anymore and the power of social networking means that such views are exchanged widely and instantly

He also says ….
"The people we employ today . . . want to be able to bring their own tablet or other device to work rather than using the standard IT department-prescribed personal computer," Mr Mullen says.

"They want to work from home in the morning or the evening outside of work hours, and they want to take flexible holidays and remain in touch while they are away. Social networking is part of their lives."

The danger for managers who want to preserve the old order of nine-to-five workplaces and a hierarchy that assumes the boss is always right is that they lose their best staff. Some may even leave to set up a rival business.

"Failure to embrace the new way of working will literally see older, established businesses go to the wall and Generation X- and Y-led new businesses take their place," Mr Mullen says.

Read the complete article here

Importance of Definition of Done and Ready checklists

Here is my article published on TechWell….

Much has been written about definition of ready (DOR)and definition of done (DOD) lists, but not a lot has been written about the lists’ importance. Additionally, not very much has been written about the issues surrounding these lists.

DOD and DOR lists are similar to the checklists that restaurant chefs use while creating recipes as well as before serving food to customers.

Chefs validate their mental checklists to ensure the availability of ingredients before preparing food. In the absence of this checklist, chefs have to run around looking for each ingredient, which not only wastes time but also stresses out everyone.

I would like to use the chef analogy to show the importance of DOR and DOD lists. Having the right DOR checklist provides you confidence to begin a sprint, and the right DOD list improves a team’s credibility in front of the product owner.

In addition to helping the team check sprint readiness, DOR checklists expose inherent weaknesses of systems. In one case study, a team without a DOR checklist consistently failed to deliver value toward the end of each sprint. However, upon introducing DOR lists, a major issue was discovered followed by a clear solution.

Similarly, having a good DOD list reduces the risk of misunderstanding as well as the communication gaps between the delivery teams and the stakeholders. Always remember to have both DOR and DOD lists together; signing up for a DOD list without a DOR counterpart could result in stressful situations as the teams keep signing up for things without checking their readiness.

Read the complete article published on TechWell

How to build a self organizing team

Building a self organizing team is every Agilists dream.  Once in a while we hear some stories of successful implementation, and here is the one I came across recently. 

Here is a great story I am going to share, but you would be astonished to see that it is not from a software team but a nursing home.

Launched in April 2008, Innovative Care Models provides detailed profiles of 24 successful care delivery models. These profiles were developed as part of a research project conducted by Health Workforce Solutions LLC and funded by the Robert Wood Johnson

One of the models they have applied is the Self Organized Agile team

The goal

Self-Organized Agile Team was developed to address three interrelated nursing problems facing Prairie Lakes Healthcare System (PLHS):  poor employee morale due to work intensity and lack of teamwork, high turnover and low productivity.

What exactly they did to build the self organizing team
The hospital placed decision-making authority for work redesign close to the front lines so bedside nurses could make independent decisions and find ways to improve operations.  In addition there was a goal to shift to a unit culture in which every nurse touches patients.  As a result, jobs were restructured to eliminate nursing roles that did not provide hands-on care.  The hospital eliminated the assistant nurse manager, charge nurse, and case manager positions and developed more effective systems to incorporate these clinical leadership functions into the bedside professional nursing role without adding to workload.  The unit also eliminated the unit secretary position and blended the responsibilities with the traditional nursing assistant role by cross-training unlicensed staff to fill either position. 

Key takeaways from the story
1. They gave importance of  hands-on people
2. Replaced the managers
3. Ensured that the decision makers are close to the people on the ground
4. Introduced the cross functional behaviour


Read more here about the fantastic results they have achieved by embracing the self organizing concepts.