Category Archives: Uncategorized

How to Introduce a Test Driven Mindset

Learn more about transforming people, process and culture with the Real Agility Program

Recently, I was helping a friend of mine introduce OpenAgile into their environment. They are a software development house with some local and some overseas developers. I am occasionally following up with my friend to see how they are doing.

Their development has been going well since adopting Agile practices with the exception of a recurring problem with “returning bugs”.

A bug will be discovered, fixed, and then several weeks later will show up again after some other modifications.  This is a sure sign that Test Driven Development is not happening.

Consider the following:

  • There is a master data entry screen called “Shipment Entry”.  The first field on the form has a “Shipper” field that allows the entry of a Shipper Code.
  • If you press CTRL-N, you Should get a sorted list of Company Names ordered by CompanyName, paged 20 at a time, with a smaller selection if some of the characters of the company name have been filled out.  The resulting list should appear within 3 seconds.
  • Today you downloaded the code, recompiled and find that the drop down does not sort anymore.
  • You know that you have fixed this before.

Introduce the Test Driven Development Mindset.

Instead of opening a ticket, sending an email, complaining or whatever your process is, consider trying the following and introducing something like this into your source / version control.
Shipment Entry Screen Tests
Shipper Field is Empty, CTRL-N pressed List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has “ABC”, CTRL-N pressed List Appears (filtered to show all companies containing “ABC” in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has an invalid entry “INVALID”, CTRL-N pressed Within 3 seconds, a pop-up appears indicating “NO COMPANY FOUND”, the shipper field is blanked and the cursor is returned to that location. The popup disappears.

If any developer works on that screen, before checking in, they need to do all the tests on the SHIPMENT ENTRY TESTS document to ensure they have not broken anything.Don’t get me wrong. The idea is not to document the entire screen up front! Try to avoid designing the ENTIRE UI up front in this way. That has it’s own non-agile problems. This is just an easy way to introduce future changes using a different mindset.In my example above, there is a field called “Mode of Transport”. It currently shows a list of numbers which internal employees “KNOW” from years of experience with the application. When that number is selected, it gets converted into something like “MAIL”, “COURIER”, when it is printed on the final document. Your team has agreed to do work to have it show the appropriate labels in a drop down on the screen.Traditionally (non-test mindset), you would send out an email or open up an issue with a request for this change. Then, the cycle will continue again. As time goes by, you will always need to re-check this is working properly.

Try something like this instead:

When you have finished your planning and have decided this “story” or “feature” will be introduced to this cycle or Sprint, simply modify this document as follows;

Shipment Entry Screen Tests
Shipper Field is Empty, CTRL-N pressed List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has “ABC”, CTRL-N pressed List Appears (filtered to show all companies containing “ABC” in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has an invalid entry “INVALID”, CTRL-N pressed Within 3 seconds, a pop-up appears indicating “NO COMPANY FOUND”, the shipper field is blanked and the cursor is returned to that location. The popup disappears.
Mode of Transport Entry into Field Within 1 second, when entering this field, a drop-down list appears show full descriptions, sorted alphabetically by Mode of Transport.

Granted, the tests will eventually become cumbersome. However, please remember that someone will eventually be testing these screens and find these bugs in a never ending circle. My friend found that every morning they were having to go through all the screens to see what “new things” were broken.

Why not just try to get it right during your Cycle or Sprint ?

In the above example, as soon as someone takes on this task, they will have a failing test (Red), they will do what they need to do to get the test to pass (Green), and then will adjust the code to be efficient (Re-factor).

Although Test Driven Development is better done at other places in the code, this is a great way to introduce the “Mindset” into your team.

Someone will eventually say “This is getting to be a hassle. Can we automate it somehow?”, which as an Agile person is exactly the words you eventually want to hear.

Maybe now, you can start to introduce it at the Unit Test, or Functional Test or whatever level is appropriate to your organization. There are some more formal ways of doing TDD such as Extreme Programming (XP).

The important thing is that your company will have shifted to a Test Driven Mindset.

The quality of your product will increase and stay that way and the need to go back and fix old bugs in a never ending cycle can soon be a thing of the past.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What if your first cycle ends up with zero story points completed?

Learn more about transforming people, process and culture with the Real Agility Program

I recently introduced a small software development company to the ideas of Agile development, the culture of Agile, and of course some of the fundamentals of working in incremental steps.  We focused specifically on OpenAgile.

They started their first cycle with great enthusiasm and with as much attention to detail as possible, but still ended up completing zero story points in their first cycle. Is this is a disaster ? The short answer… NO.

The company has gone through two major releases based on non-agile methods with limited success. One of the owners of the company has been a long time friend and we discussed doing some Agile training with his employees to “see how they felt” about learning about OpenAgile.

There were no commitments made to it. The idea of “Hey, let’s learn about this and see if it’s right for our organization” was the goal. All the team members were told that the company was considering (with emphasis on considering) switching to OpenAgile and would not do it if everyone didn’t feel like it was worth the effort and made sense for them. It was stressed that OpenAgile is not a silver bullet and may not be right for them. The effort was purely exploratory in nature.

As this company is in software development, Agile development easily made sense for them. They were so excited by the OpenAgile training, the developers and the owners decided to immediately abandon their existing plans for development and refactor.  The fact they felt they could do this shows true management leadership and support for the process.

I have to congratulate my friend for his courage in supporting his team.

The team determined that they were working on functionality which would not provide the greatest Return on Investment and decided to adjust their priorities accordingly.

A great deal of our time was spent during the training on the ideas of Consultative Decision Making and encouraging openness between those involved in the process. All team members are encouraged to be open about their opinions during planning and if they find something wrong during the cycle, to speak out.

I find that having management and stakeholder support and encouragement in the process is almost mandatory for Agile to work. Without the understanding from the owners of the company, the culture required to make it work will inevitably cause friction “around the edges” of the Agile team.

We spent time on the concepts of ROI (return on investment) and how to apply it to estimating, planning, re-estimating, and selected work. In using OpenAgile, we want to work on the tasks that give us the biggest value over effort factor or ROI.

We followed the OpenAgile syllabus. As an OpenAgile trainer and mentor, I had easy access to material to teach in an organized fashion.  Their environment is complicated by owners in multiple cities and developers in 3 different cities including an overseas component.

Openness about the potential pitfalls of remote teams made a big difference to the attitudes of those taking the training and the final outcome. Learning OpenAgile, Scrum, XP Programming, or any Agile process is difficult enough without adding the component of two remote teams and overseas development.

Many people leave their OpenAgile training realizing that it is a very effective framework and are anxious to get rolling. Because this company and the team decided to continue with OpenAgile, they started the preparations for the first cycle to begin the following week (after a long weekend break).

The cycle started, cards were created as Story Points, and the work began in earnest. They had many surprises. I had been unavailable through their first cycle and had very little ability to keep up with how they were doing because of a new Scrum Team I was working with. In retrospect, I am glad I was not there to give advice. They did fine on their own :->

In true Agile form, they figured out on their own what was going wrong and when I talked to the owner several weeks later I found out that they had already determined their mistakes.

The team was actively taking steps to improve the next cycle.

If senior managers encourage the right environment and let the team self-organize… you know what.. they likely will :->

Things that went poorly

  • Two days into the cycle, some of their overseas developers went “to visit family”. They did not realize at the time, this was local code for “going on holidays”. I heard from the owner later that if they had not asked why they did not get responses to emails, they would not have known the other developers were away.
  • The Stories were Too Big. Because of the combination of the new way of doing things and the excitement about how much could get done as an Agile team, the team bit off more than they could chew.
  • Attempts at Test Driven Development did not go well.
  • The first two week cycle stretched to 3 weeks because the team didn’t want to have Zero velocity as they felt this was a failure
  • One display bug crept into the first demo related to two different ways of refreshing data on the screen

Things that went well

  • The team talked regularly about how they were doing and worked on regular status updates to determine where they were during the cycle.  This is also how they found out about the missing developers.
  • The owners and managers had an active involvement in helping to remove obstacles.
  • The team found an intriguing way to determine how many story points they could actually commit to in future cycles.
  • The team figured out how to deal with code sharing and peer review type issues related to being at opposite ends of the earth.
  • The team stayed together and focused on the goal of creating potentially deliverable product
  • They were able to successfully work on two simultaneous streams of work on different parts of the system.
  • During the demo, the team was able to demo functionality that could potentially be brought to a customer after only two cycles.

Summary

I had a discussion with the owner recently and he told me they all sat down and realized their mistakes of their first cycle. They consider OpenAgile to be a success.

The team was so worried about not completing story points, they considered it to be a failure to not finish at the appropriate time. You need to let newcomers realize that not completing all the story points of the first cycle may happen.  This can be compounded by added complexities of your working environment or project.

Since they were pushing to get the points completed, they were sacrificing quality. They were rushing because they knew they had gone past the end of the cycle and it was causing more problems each day it continued. Thankfully, they stopped the cycle and decided to do the right thing and demo where they were and talk about their progress.

They simply took on too much work, didn’t account for all the other overheads of a new team setup and issues that would take place with their remote environments. This did not mean failure. They learned how to re-organize themselves for future cycles.

With the support of the owner and a little bit of moral support from myself, the team realized they had accomplished a great deal already in their first cycle.

They realized they need to put some better controls on the holiday schedules of the remote teams overseas or at a minimum find out what is expected in this regard.

The team realizes it has a deficiency with Test Driven Development and is working on plans to allocate some time for training on this very important task. Perhaps their one bug from the first demo may not have been there with Test Driven Development in place. They will continue to work toward improving this.

One of the great things to come out of their first cycle…. A potentially deliverable product within the first two cycles!

When I reviewed this with the owner he told me the completed work is already faster and better than their previous system which took 5 years to write. Considering the remote component they are dealing with, this is truly great news for them. Their first cycle has produced software which can now simply grow organically.

Some advice here which I shared with my friend.. Make sure that you have at least one story that can be finished in the next cycle, no matter how small.  Consider it of huge Value to the Agile process.

You need to provide some positive feedback for the team members now.  This does not mean the team should agree to less work than they think they can accomplish. Simply encourage some work that can be completed to be included in the next cycle.

For my friend, although they completed zero story points in the first cycle, they are happy to know that if they just adjust the size of their stories for more attainable results and use what they learned from the first cycle, OpenAgile will work out well for them.

The concepts of Consultative Decision Making, Continuous Learning and the Learning Circle allowed them to truly excel and will allow them to continue to do so into the future.

They are looking forward to shipping their new product in record time :->

One comment that was made to me was something along the lines of “Hey Mike, this reminds me of when we used to work together in the garage when we started the company. We all worked together on whatever needed to be done. That’s what made us successful in the first place.”…. Hmmmm.

Mike Caspar, CSM, OA2/5

References: OpenAgile – www.openagile.com


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Agile Tour Toronto November 3

Learn more about transforming people, process and culture with the Real Agility Program

This is just a quick post to share that Agile Tour Toronto is coming soon. It is on November 3 in Toronto. It will be a great day with plenty to do, much to learn, and so many people to meet.

We will be there too. Berteig Consulting has a booth and many of us will be there to meet all of you. Hope to see you there!

Here is the link: http://www.torontoagilecommunity.org/att2011


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

WHY? Such a powerful question

Learn more about transforming people, process and culture with the Real Agility Program

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/


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Upcoming Scrum + OpenAgile + Kanban training – Edmonton

Learn more about transforming people, process and culture with the Real Agility Program

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Upcoming Scrum/Kanban/OpenAgile Seminar in Waterloo – May 4-6

Learn more about transforming people, process and culture with the Real Agility Program

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Awesome iPhone Tool: RectAce

Learn more about transforming people, process and culture with the Real Agility Program

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Helpful outline of the OpenAgile Primer

Learn more about transforming people, process and culture with the Real Agility Program

David Parker, the Executive Director of the OpenAgile Institute, published a helpful outline of the OpenAgile Primer on his ‘Changemaker in the Making’ blog. Take a look at the Conceptual Outline of the OpenAgile Primer and let it inspire your own thoughtful study.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Our new 3-Day intensive Agile methods course

Learn more about transforming people, process and culture with the Real Agility Program

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.

http://www.berteigconsulting.com/


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Coaching is Accompaniment

Learn more about transforming people, process and culture with the Real Agility Program

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)


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Great Article on Shu-Ha-Ri

Learn more about transforming people, process and culture with the Real Agility Program

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!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile is Not Communism – Repost

Learn more about transforming people, process and culture with the Real Agility Program

“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!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail