WHY? Such a powerful question

Recently I was watching a situation with a development team where a very important question seemed to be forgotten… WHY ?  This got me thinking about the countless times I have seen work done for no apparent reason than it’s “On The Wishlist”, “We have a card for it”, or “Because Customer Service Says So”.

Many times I have seen features get created where at the end of the release, the final user of the feature says, “Oh, we haven’t needed it to do that for about 3 months now”.  This part of the requirements is long gone.

This brings me back to Waterfall Methodology and something I would expect to see. With it’s linear approach to the Software Development Cycle, it is almost to be expected that there will be some waste of this nature.  This is not to say that Waterfall is never appropriate.  It is just an expected part of the process if you have a long development cycle.

However, using an Agile Methodology such as Scrum or OpenAgile, this should simply not happen.  Agile methodologies are based on Communication.  This communication is paramount during the Sprint or Cycle but is absolutely mandatory during the planning meeting. A team cannot simply be given a list of instructions to follow.  The team needs to understand what their Goal is.

In Scrum, the Product Owner is responsible for guiding the team as to which features should be queued up next based on Return on Investment (which generally means actually needed).

In OpenAgile, the team has a similar approach of consultation with the “end user’ and the planning of work based on Return of Value, and plan appropriately.

Although in Scrum and OpenAgile, there is discussion about Return on Investment, Value, bug free code, Test Driven Development, etc. there often appears to be little discussion about the idea of why we are doing something.

User Stories, if done correctly can significantly improve this problem because the “story” needs to have a goal as to who benefits.  We are doing this Feature for this “x” to get this benefit.

It is however, the responsibility of a Team to ask “Why would someone want to do this ?”, or “Why are we updating this information in the first place”. Often, the insights are very revealing.

Let’s take a simple example.

I the late 80′s, I was working as a developer with a company where the company’s approach was to provide the developers a “requirement” , choose a developer and send them off to do the work (pre-Scrum days).

The developer was to modify a Stored Procedure to go through a table and update every 3rd record in the table to be 50% higher.  It was a fairly complex procedure and a developer at this company spent almost a week re-writing the procedure and getting it implemented. The development team sat down with the engineers and customer and developed a method of testing and verification, backups of the database were made and the implementation work began.

No one asked Why.

Several weeks later a similar request was made in a different part of the system. I spent some time with the developers and encouraged them to ask Why the first modification was made.  The answer was “That is what Sherry said to we should do.  The customers are yelling and this is what we need to do to fix it”.

Those of you using Scrum or OpenAgile are probably already cringing and thinking.. Gees… you could write a book just on this one paragraph alone.  I’ll leave that for another day :->

The actual problem was there was a different part of the system which updated the tables based on Quarterly Results.  This was the actual reason every 3rd record in the table was wrong.  That procedure was incorrect and shared by other parts of the system.

If someone had not stepped in, this cycle of fixing the by-product of the defect could have gone on for many more months.

I convinced the owner to change the procedures to allow the developers to ask questions as a team before work was queued up. I simply asked for this one simple right.

A few months later, the overall bug rate of the application went down, customer complaints went down and the development team started to feel engaged and part of the process.  It was a different place after that.  People enjoyed working there.

As part of the planning stage of your Sprint or Cycle, please consider asking questions such as

-Why are we changing the Field Size from 80 Characters to 250 Characters ?
-Why should the system need a procedure to update these types of records .. Doesn’t the system do it properly ?
-Why would we want to force through Credit Card Transactions without the CVV Code (the security number) ?
- Why are we making a whole new authentication system ?
- How did this become a requirement ?

This type of question is not intended to be a confrontational thing!  Often those requesting the features may feel that you are being confrontational.  Remain calm, and make sure to let the requester know this is a standard part of your process and not a question of their power or knowledge.  The goal is to get knowledge, and not to figure out who is right or wrong.

After discussing it with the person, you may find they do not have a true understanding of why they are requesting the feature or change.  It is possible the idea of what or how to do it will change just from the communication alone (which is when you want it to happen.. not after it’s done).  The discussion may also allow the product to be better than they originally envisioned.

OpenAgile has a term called “Consultatative Decision Making”.  It is the idea that decisions are made based on consultation and discussion with all those involved that may have valuable input to making a decision.

Scrum also values discussion and communication as a fundamental part of Development.

The FIRST value of the Manifesto for Agile Software Development is “Individuals and Interactions over processes and tools”

In the case of the example above, we chose to fix the stored procedure which was creating the bad data and wrote a one-time script to adjust the corrupted records. We never had to revisit this problem again.

It sounds simple enough, but the basic premise of WHY is absolutely mandatory to this process or all decision making will be based on following instructions blindly with no sense of ownership by the team.

References :

Scrum – http://www.scrumalliance.org
OpenAgile – http://www.openagile.com
Manifesto for Agile Software Development – http://www.agilemanifesto.org/

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

AgilePM+Scrum(CSM)+OpenAgile+Kanban July 6-8 in Toronto

This 3-day training covers 3 Agile methods: ScrumMaster (the most popular Agile method), OpenAgile (the most widely applicable Agile method), and Kanban (a method that can be used together with other Agile methods).

Learn more at:http://www.berteigconsulting.com/ScrumCSMOpenAgileKanbanJuly2011MarkhamTorontoOntarioCanada

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Top 200 Agile Blogs – Agile Advice is #22!!

Wow – thanks to everyone who links here, reads this blog and tweets about it! You’ve helped this blog score at #22 in the top 200 agile blogs list!!!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

ScrumMaster + OpenAgile + Kanban training – Toronto (June 8-10)

Just a quick note to let people know that there are spots available in the seminar we are delivering on June 8-10 in Toronto, Ontario. This seminar includes Level 1 of Scrum: Certified ScrumMaster & Level 2 of OpenAgile: Certified OpenAgile Team Member plus Kanban.

Registration and details can be found here.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Why is hardware being forgotten by development companies?

This week I met someone while on a personal trip who is in the software business.  His company writes software for a very specialized vertical and from everything he said to me, they are an innovative company and do all the right things including empowering their teams to self-organize, regular training for the staff and generally a great working atmosphere.

The company has still been struggling with getting their product to be “deeper” (his word) for their client base.

I was again reminded of a post of mine from a while ago encouraging or providing cross-training or at least some knowledge to bridge the barriers between the software group and the hardware group (link at the bottom of this post).  In my environment, I’ve been fortunate to have a network admin sitting with our team.  It has prevented many potential problems.

Having been involved in the infrastructure part of IT as well as development, I knew of at least a few products almost immediately that could make his product more compelling to his customers.

To my surprise, I found out his company was only looking at software improvements to their application.  He told me how they are continually developing new features but are not considering running on any new platforms.

I mentioned a few technology (hardware) improvements he could consider and I know that by the time he gets home this weekend, he will have taken a look and passed the information on to his team.  These improvements could immediately add significant customer retention and usability to his product.

From our discussion, it was also evident that his team would enjoy the challenge of some new platforms to keep encouraged about the future. I’m sure that by the time he reads this, he’ll have some of these technologies in hand :->

As Agile practitioners, it seems, we are so focused on improving our software development cycle, our specific development tasks, our daily or hourly builds, our programming skills, and how we create story points, sometimes we seem to lose track of the big picture… What is the customer going to use it on?  This should be fundamental to every developer’s thought processes.

Think to yourself,  ”HEY, should we be seeing if our software could run on some of the new technologies out there such as Microsoft Surface, some of the new Wireless Devices, or even benefit somehow from new 3D technologies coming out”?

I like to think that developers who are empowered with information about hardware can think of all kinds of ways to use it.

If you’re on an Agile Team or managing one, ask to learn something about the hardware in your environments.  Consider some “slack” in your Sprint or some work breaks in your Cycle to allow team members to learn something about new Infrastructure or Hardware products.

Think for a moment if your company is writing software for the Web, the power of a deep understanding of how a load balancer actually works, or my personal favorite, the .NET Cache.

Let it be the teams’ choice of which products though. That will give the best motivation and most likely will be the most enjoyment for everyone.

It will broaden your horizons and perhaps give your team ideas you never knew could even be possible.

If we always just wait for a Marketing Person or Product Owner to come up with interesting ideas, where’s the fun in that?

References :

My previous post – Infrastructure Knowledge for Developers
3D example – Sony 360Degree viewer prototype
Microsoft Surface – Microsoft Surface Web Site
Slack – A good article about slack in XP by James Shore
Sprint – Scrum Alliance
Cycle – Open Agile

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail