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.
Just a quick note to let people know that there are spots available in the seminar we are delivering on May 25-27 in Edmonton, Alberta. This seminar includes Level 1 of Scrum: Certified ScrumMaster & Level 2 of OpenAgile: Certified OpenAgile Team Member plus Kanban.Details can be found here.
Just a quick note to let people know that there are spots available in the course we are delivering next week in Waterloo. Details can be found here.
Sure, the name isn’t the greatest, but this little tool is fantastic. Basically, every agile coach knows that you need to take photos of whiteboards, and every photo of a whiteboard either looks super crappy or needs to be processed after the fact to make it presentable. RectAce does it for you. It detects the edges of your whiteboard (or any other major rectangular feature in the photo), and then does all the color and contrast adjustments necessary to make it look nice. Here’s the link to the iTunes store for this app: RectAce.
We have made some changes to our already well-received Certified ScrumMaster training seminar in order to add more value for our customers. Beginning in September 2010, you will see the following:
– Our seminar is now a more effective, participatory 3-day seminar giving more value for your time by including OpenAgile and Kanban along with Scrum
– Our preparatory reading material replaces lecture-oriented course content to allow more effective use of classroom time
– The Scrum Alliance knowledge test helps you consolidate your learning of the core Scrum principles and practices
– Our seminar contributes towards three certifications all in one course: the Scrum Alliance’s CSM, the PMAC Agile Project Management and the OpenAgile Institute’s Team Member level
All these changes help participants to be more engaged in their own learning, and derive more value from this seminar. Our seminar combines with the real-life experience of our facilitators to provide some of the best training value available! We will show you how to radically improve the performance and quality of the work of your team and organization.
I have been coaching an Agile-Lean team in Waterloo over the last month or so. It has been very rewarding for me (and the team I hope). I have learned that coaching is very much about accompaniment. To have a positive effect on the team that one is coaching, we need to walk shoulder to shoulder with them. The exhaustion of coaching (physically) is well worth the learning and advancement (mentally and spiritually). It is so valuable to witness the “a-ha” moments and have some of my own light-bulb insights. It is such an honour to serve as a coach for any team, especially if that team makes you feel like one of the team members. (Paul J. Heidema)
A close associate, David Parker, has written a great little article about the use of agile methods in volunteer management.
Christian Gruber, a Googler, an agile guru and an Aikido practitioner clears up some important mis-understandings about Shu-Ha-Ri as applied to both learning Agile and learning Aikido: http://bit.ly/bqgvZS . Strongly Recommended!
“Last week I taught an introductory course on Agile Work. Normally this is pretty easy stuff. However, I was teaching this course in Bucharest, Romania (cool), and I have come across a substantial, strong and vigorous objection to agile (also cool, but challenging too). Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either. I’m looking for help on this! …”
Read the original article!
Here is a collection of interesting reads and articles that either Mishkin Berteig (@mberteig) or Paul Heidema (@paulheidema) reposted on Twitter.
You can join Twitter by visiting http://twitter.com and following their steps.
If you are interested in what OpenAgile or other agile methods are all about please follow @mberteig @paulheidema and many others of the ones listed above.
OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?
The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.
OpenAgile is an improvement over Scrum in the following ways:
More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
applicability over a larger range of team sizes from a single individual on up.
Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment.
Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
environment. OpenAgile also provides a framework to include additional types of work beyond these five.
Improved role definitions based on extensive experience.
There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).
There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.
The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:
- is not responsible for team development
- is not necessarily a single person, nor is it a required role
The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:
- is responsible for all aspects of growth including value (like the Product Owner), and individual and team capacity building.
- is not necessarily a single person, nor is it a required role
Integration of principles and practices from other methods. Two examples suffice:
From Crystal: creating a safe work/learning environment.
From Lean: build quality in, value stream mapping, root cause analysis, standard work.
OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
unsuitable for operational work and general management.
The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.
Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal.
The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.
Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).
Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.
Comparative Glossary between OpenAgile and Scrum
|Cycle Planning||Sprint Planning and Sprint Review|
|Team Member||Team Member or “Pigs”|
|Growth Facilitator||Product Owner|
|Work Queue||Product Backlog|
|Work Queue Item||Product Backlog Item|
|Cycle Plan||Sprint Backlog|
|Progress Meeting||Daily Scrum|
|Learning Circle w/ steps||“Inspect and Adapt”|
|Delivered Value||Potentially Shippable Software|
|Five Types of Work:
New, Repetitive, Obstacles, Calendar,
|– no equivalents –
User Stories, N/A, Impediments, N/A, N/A
|Consultative Decision Making||– no equivalents –|
|Sector / Community||– no equivalents –|
References on OpenAgile:
References on Scrum:
“Agile Software Development with Scrum” – Schwaber and Beedle
“Agile Project Management with Scrum” – Schwaber
“Scrum and the Enterprise” – Schwaber
Berteig Consulting is thrilled to announce the early release of the OpenAgile Primer, version 1.0, now available for download at http://www.openagile.com/TheOpenAgilePrimer. This release falls 2 weeks ahead of the scheduled release date of 1 December 2009 thanks in large part to the implementation of OpenAgile itself in the creation of the document.
The Primer is intended as an introduction to the methodology of OpenAgile as well as required reading for the soon-to-be released OpenAgile Readiness Knowledge Test. Successful completion by individuals of the Readiness Test will result in the award of an OpenAgile Readiness Certificate—the prerequisite for OpenAgile Team Member Certification.
The team wishes to thank all those who have generously contributed to the realization of the first version of the Primer and looks forward to collaborating with many more of you in the future.
We will keep you posted as the work progresses.
The Berteig Consulting Team
We have wrapped up our Summer Special. There are still a few classes scheduled this year that have the discount price, but others have reverted to our normal price. I encourage you to take a look at our course schedule at http://www.berteigconsulting.com/ to see what is still available.
Also, all our future Certified ScrumMaster courses will have a knowledge test as part of the certification process. Please see the Scrum Alliance website for more information at http://www.scrumalliance.org/.