Also, the learners themselves experience various challenges  that inhibit their ability to use the new skills on the job immediately.  They leave the formal training environment and:

• Day to day pressures of their responsibilities take over
• Their work environment isn’t ready
• Their leadership team isn’t prepared to support  the new skill
• They  lack confidence and understanding about how to use the skill when they face a
  particular situation
• They are naturally resistant to change

This situation results in what we in the corporate training  world describe as “cold storage” issues.  The participants forget what they learned.

We’ve all been there; we complete a training course that energized us; one that taught us skills we knew would have a significant positive impact
on our work and are excited to try.  We  thought we had all of our questions answered during the training to be able to  use it in our world.  But then, we arrive back into the day to day operations of our roles and we get caught up in the same old same old… “just until we have more time.”  Before we know it, 2 weeks have past and when we attempt to utilize the skills we learned we have totally forgotten where to start. Or possibly the scenario looks like this; we get back on the job and  attempt to incorporate the new skills but a scenario arises that we are not  sure how to handle. We get frustrated. We ask our leader but they don’t have the answer, they just learned these new skills too, or possibly they didn’t
attend the training at all.  These  barriers result in our falling back into the old way of doing things, or implementing the new skills incorrectly and therefore not achieving the business results required.

As a corporate learning consultant for more than 10 years, and having experienced these scenarios over and over again, I am very excited about the post training coaching offering we have at WFS.  It is a “perfect world” scenario for training success.  A virtual guarantee of transfer of knowledge and skills to the job once out of training! Our instructors, who are also software development life-cycle (SDLC) subject matter experts and coaches, will follow the learning cohort back into the “real world”, supporting them through the implementation phase and through the problems and challenges they face in real time.  This results not only in true learning transfer, but the promised %40 SDLC business improvement.

Be sure to contact us to learn more about this exciting service offering.

Our client,  an online retailer, was the first to experience the course instructed by our own Rod Bray, Certified Scrum Master and software architect. The participants were a combination of software developers, quality teams and business analysts.  This was the perfect audience to test our gap theory.  The theory that our customers want a course that takes  Agile principles that a firm like Berteig offers, and applies them directly to software development, taught by someone who can answer real-life software project questions, someone who’s been there, someone who has scars to learn from and success stories to inspire.

The results of our experience with the Agile Boot Camp this week indicate we were bang on.

The participants completed our course survey that we use to measure satisfaction and capture comments to improve our training offerings going forward.

The feedback form uses the Net Promoter Score (NPS) customer satisfaction measure that defines “success” as having more promoters (people who would recommend the training to a peer), than detractors (people who would tell a peer not to take the training).

Participants respond on a 10 point rating scale and are categorized as follows:
Promoters – Select score of 9 or 10
Neutrals – Select score of 7 or 8
Detractors – Select score of 6 or below

Our NPS was 65%  which is a very positive result when benchmarked against average NPS results that hover between 5-10%.  Very positive results are considered to be over 50%. In our course there were 0 detractors, meaning not one participant selected a score below 7 on the rating scales.  This is a further demonstration of very strong satisfaction with the course.

Some participant comments shared on the survey were:

“Content was very relevant…”

“I’ve worked in the past with “agile” teams, but now after more formal training…know what was missing and why it was not successfully applied.”

“…the instructor has the knowledge and having the team from the same company made learning easier.”

“…interaction with the instructor helped a lot.”

“Generally I don’t enjoy group work during training…However the exercises in this course were quite useful AND enjoyable.”

Of course, we also received constructive comments that we are absolutely going to take away and incoporate into the subsequent iterations of this course.

Our overall experience this week was very positive and we can’t wait to deploy the next iteration of the course that will be even better!

A big thank you to the online retailer team for their participation, enthusiasm and feedback!

We recently reviewed the Toronto market for Agile training and what we found some great Agile Scrum and Scrum Master Certification training.  But we could not find any courses that were focused on both Agile and software delivery.  Berteig Consulting provides excellent training; in fact our Scrum Master was trained by Berteig, and I would recommend them to anyone looking to obtain the CSM designation.

However, what we noticed was the need for a course that takes the Agile principles that a firm like Berteig offers and applies them directly to software development.  Our clients are asking for an Agile training course that is taught by a software architect and ScrumMaster. A course taught by someone who could answer software project questions. A course taught by someone who has been there and has both scars to learn from and success stories to inspire others.  We felt a course like this would help teams make faster progress at achieving the benefits of Agile.

With this concept in mind, we are now offering an Agile Boot Camp for software delivery teams.  It is taught by a ScrumMaster who is an experienced Enterprise Software Architect.  It’s a specialized class that puts software teams and individuals on a path of improvement.

The course is ideal if you are part of a software team using Agile Scrum — or are considering Agile for your next project — and want to learn how to implement this new approach.

Scrum Meetings – those 15-minute “stand up” meetings that we do every morning – are a simple, powerful tool to keep your project moving.  But it’s easy to go off the rails and lose the effectiveness of these meetings.  I’ve listed five tips that we can emphasize which will optimize our Scrums.

1. Start on time and keep to schedule.
   It’s a little thing with big consequences.  Like other meetings – Sprint Planning, Sprint Retrospective, Sprint Demo – we are making a statement about the importance of time.  Subtle lessons are communicated when an entire group is held up waiting for someone to arrive or the Scrum is delayed while some other activity is completed.
2. Don’t get hijacked.
   There is a time and a place for elaboration on a solution or a difficulty, but it’s not in the Scrum.  The Scrum is so effective, in part, because it’s short but packed with essential information.  Anything that may transform the Scrum into something else should be taken “offline” or form the basis for another meeting – peer review, user story elaboration, design meeting, etc.
3. Have a proxy if you can’t make the meeting.
   It’s important that everyone is able to contribute to the Scrum.  If someone is going to be absent or late, then they should assign someone else to speak on their behalf.  After all there are only three essential pieces of information to communicate. …
4. Only ask (or answer) three things.
   The Scrum is all about determining and ensuring progress so there are only 3 things that everyone needs to communicate: “What have I completed since the last Scrum?” “What will I be working on today?” “Is anything blocking my progress?”  The Scrum Master will use this information to chart progress and remove impediments to keep the Team progressing.  Team members can also use this information to spark collaboration (outside the Scrum) to support each others’ efforts or transfer skills and knowledge.
5. Record results.
   Technically this is done after the Scrum by the Scrum Master. But it has been my experience that Team Members look forward to seeing the results reflected in the burn down Chart very shortly after the Scrum.  It has been a great motivator to “keep below the line” on the burn down and it can affect the day’s work if the results are not available in a timely fashion.

The Scrum is very simple and is often given little attention when organizations are seeking process improvements.   But the Scrum is also a powerful way to spotlight successes and problems.  When done correctly, it makes a significant contribution to building high performing teams. Be aware of whether your Scrum meetings are efficient and effective and the entire team will be rewarded with better communication and motivation.

Consider attending one of our Scrum Training sessions to learn the basics of any Agile approach, the three roles defined by Scrum, how to build a product backlog, and how to plan and work in Sprints.

IBM Canada recently invited Web Financial Solutions (WFS) to participate at an IBM Conference called Innovate Comes to You.  This conference is a smaller local one-day version of a much larger five-day conference that occurs once a year in Florida called “Innovate.” It’s IBM’s way to bring some of the larger conference’s content to localized markets.  The conference had over 150 people registered and about half of that number attended.

John Munro discussing Software Process Improvement

It’s been a while since I have been at a manufactures’ conference – usually these conferences are ‘stuffed’ with a great deal of product information. This conference had a good deal of product and tool information but it also had a valuable theme. That theme was using an Agile-based approach to help improve software development.  IBM is now using Agile (Scrum) in the development of their tools. The keynote speaker showed slide after slide of improvement metrics used to measure the improvement of Agile based projects. Each slide showed about a 50% improvement over a two year improvement process. I found that particularly interesting because that mirrors almost exactly what we are seeing.

Overall, Agile is playing a big role in IBM’s approach to software development both in tools and internal approaches.

What was on the minds of people at the conference?

About a dozen people stopped by our display to discuss their situation.   The number one issue on people’s mind: How does the technical team get buy-in from the executive team on trying Agile as an approach to software development? The second issue on people’s mind was how to implement Agile in an environment that was currently producing software.

Connecting Agile improvement to the Business?

Connecting the software delivery process to the business priorities was the number one area of discussion at our table.  We believe that it’s important to clarify one point – Agile is not only for software delivery and it’s not a new ‘technology.’ Rather it’s a learning framework for improvement.  WFS have developed an approach to communicate Agile to the business executive with a tool called the SDLC Assessment and Improvement Roadmap. One of the deliverables of the Assessment is a Radar map showing key business dimensions and how they connect to key Agile Best Practices. We believe this helps to close the gap for business leaders to better understand where to start.

How to Implement Agile into an existing process?

Last week I had the opportunity to talk to two different companies, each had a similar story about going head-on into an SDLC improvement with a software manufacturer.  One company was a financial services company and the other was a manufacturer.  The results were almost identical – failure.  Why did that happen and how do we prevent it?  We believe it important to have focused improvement that is done incrementally.  The improvement is measured with meaningful metrics so it’s self-funding.  We only discuss tools after the process has been internalized by the team.  We believe this is the best approach.

If you are interested in discussing your situation with a Agile Coach, please fill out the form on the right and we will be sure to contact you. Or if you prefer just give me a call 416-505-4756.

The Law of the Few contends that before widespread popularity can be attained, a few key types of people must champion an idea.  Gladwell defines the Stickiness Factor as the quality that compels people to pay close, sustained attention to a product, concept, or idea.

The concept that Gladwell terms the Power of Context is enormously important in determining whether a particular phenomenon will tip into widespread popularity. Even minute changes in the environment can play a major factor in the propensity of a given concept attaining the tipping point.  It’s this area that really turned things around on our current project.

We developed a game that awarded points based upon measured code coverage supplied by tests.  Our automated Continuous Integration system ran these automated tests and produced the results.  We have detailed on-line reports showing how much of the code base is “under test.”  Points were awarded for new tests, fixed bugs, improved code (based upon static code analysis) and delivered features.  Points were deducted for broken builds and improper coding idioms introduced.  And we made the “Leader Board” highly visible.

In a single three-week Sprint, more than 400 tests were created that increased code coverage by more than 10%.   Defect density plummeted and the developers were freed from bug fixes and spent their time in more interesting pursuits.   We now have the beginnings of a Regression Test Suite that will mitigate the introduction of new bugs and reccurrence of old bugs as new features are added to the project.  The same tests also act to verify and clarify requirements and head off many misunderstandings.  And, of course, the business group appreciates the noticable improvement in code quality.

I believe that we reached the tipping point and now, on our next Sprint, everyone seems to be moving towards a TFD/TDD mindset.  Of course time will tell – I’ll keep you posted.

Recently, I was invited to attend a project ‘stand up’ meeting or Scrum meeting.  A ‘Scrum’ meeting lasts 15 minutes and discusses the project in terms of its current status and what is ‘blocking’ progress.   After the meeting the leader of development team updates the ‘Burn Down chart’.  A burn down chart shows outstanding work items on the vertical axis and time on the horizontal axis and usually runs left to right.  An ideal ‘burn down’ line is drawn from top left to bottom right corner.

For a more complete description of a Burn Down chart click here.

Here is an example of a burn down chart:

Burn Down Chart

What a simple tool!

The graph was put on a large piece of chart paper which was taped in a hallway.  At a glance the team’s progress could be seen by everyone and anyone walking by. If the line was drifting to the right of the straight diagonal line the project was slipping behind.  If the line was left of the diagonal line the project was ahead of schedule.  In just under one second, meaningful data was communicated to the ‘whole team’ on the project’s progress.

Next week I will be giving a non-IT related example of how testing reduces project costs and lowers frustration.

Please feel free to contact me by filling out the contact form on the right side of this page and we can discuss metrics further or how a ‘burn down’ chart is created.  If you are interested in our monthly newsletter in which we discuss issues other executives are encountering and the lessons from an ongoing Agile project click the newsletter box.

(Please note that a sign-up box will be added shortly.)

Well, firstly, people tend to write tests AFTER the coding is complete.  This leads (typically) to superficial testing – testing the “happy path”.  And since it’s at the end, there’s never enough time to really complete this extra effort of testing.  Test Driven Development (TDD) or at least Test First Development (TFD) is generally accepted as the way to ensure that the tests are meaningful, extensive, effective and completed.  I’ll speak more to the value of TFD/TDD in later posts.

Secondly, testing isn’t really fun.  Or exciting.  Or even seen as completely necessary sometimes. (“We have a QA group don’t we?”)  The fact is, developers don’t naturally like to do it.  As a veteran of software development, I must confess that I have shared these feelings too.

People like Kent Beck speak about becoming “test infected.”  That would be the condition where developers have used TFD/TDD enough and seen the successes enough that they don’t want to code without it.  They’ve gone through a cycle of writing tests first, then coding and refactoring — and seeing the bug counts go down and the code get better as a result.  It becomes second nature.  They have a hard time going back to traditional Code First development.

So really the question is: “What can be done to get developers ‘test infected’?”  Let’s look at that question next week – I have one idea that has worked for our team.

One key point I would like to make is that  Agile is not an Software Development Life Cycle process.  Agile is a learning framework.  If you are moving toward Agile, one key thing to keep in mind - your development teams still needs a Software Development Life Cycle process.  A Software Development Life Cycle process provides structure and a framework to take advantage of Agile, otherwise there is a good chance your Agile project will end in failure.

I have talked to more than one organization that has tried and failed with Agile – but the reason for the failure was not Agile.  The failure was because Agile was not given a process to make it successful.  It’s like giving a race car to someone who has never driven before and telling them to race at the Indy in Toronto … and then being surprised when they smash up the car.

Agile can — and does — deliver benefits of faster time to market, faster delivery of business value, lower costs, but it needs certain infrastructure to hold it together. That structure is provided by the Software Development Life Cycle process.

It’s common when teams start a new Agile project to interpret the ‘Agile Manifesto’ incorrectly.  Take, for example, the first statement from the Manifesto…

 ‘Individuals and interactions over processes and tools.’

For development teams, this is music to their ears because there are no more process, no more reports, no more controls.  This statement says people and their interactions are most important.  While that is true and a key part of Agile is that it should not be mistaken to read  ‘process and tools are not important.’

Next Tuesday I will introduce one report that is most valuable in Agile – the “Burn Down Chart.”

If you are interested in discussing Agile or how to make be use of the approach, feel free to email me at jmunro@webfinancialsolutions.com or simply call my cell: 416-505-4756.

You probably know what I’m talking about – the team members have lost enthusiasm, perhaps they even believe that the project is doomed.  They go through the motions but things are missing – attention to detail, effort, creativity, teamwork. Things are generally trending downwards.

I’ve seen lots of efforts to change this – team building exercises, professional development, work environment upgrades – all of which are good.  But it’s been my experience that nothing beats enabling the team by giving them the ability to be self-directing.

In a self-directing team, the team members estimate work effort for tasks and they choose which tasks they will work on.  No one is looking over people’s shoulders or ensuring that they are “being productive”.  There is, however, a highly visible metric on the progress the team is making towards a commitment that they made “as a team.”  I’ll have lots to say about some of the mechanisms that support this in future posts.

Right now though I’m revelling in the comments of some of the team members on our latest project.  We just completed our latest Sprint – on time.  During the demos, the customers expressed satisfaction and even a little gratitude.  This led some of our people to remark – “You know, it’s never been this good!  I’m looking forward to the next Sprint.”

There’s really no telling what can be accomplished by people who are enthusiastic and committed to a goal.  I’m looking forward to the next Sprint too!!!