On top of that, we design the courses to align with the bodies of knowledge in their areas – The IIBA®BABOK® for business analysis, the ISTQB syllabus for software testing and now with the ICAgile learning objectives for our Agile Fundamentals course.
When I was first asked about designing the course I was honestly unsure – should we offer a certified Agile course? Can you certify that participants understand Agile?
Until recently the only certifications available in the Agile space were those offered by the Scrum Alliance;Certified ScrumMaster and Certified Scrum Product Owner. We had deliberately chosen not to offer ScrumMaster training, as we feel the Scrum framework is too narrow and doesn’t fully align with the approach to Agile that we offer at Software Education.
Through our association with Agile thought leaders since the very early days (our first Agile conference was held in 2002, and our first Agile course launched the same year) we have taken a broad perspective, drawing on ideas from Scrum, Adaptive Software Development, Feature Driven Development, eXtreme Programming and pragmatic experience, so to offer Scrum certified courses would have narrowed our offering, and not provided the breadth of understanding that we have built Software Education’s brand on.
It is only in the last year that Agile certification beyond Scrum has become a significant factor in the marketplace – perhaps it is an indication of the emerging maturity of Agile adoption around the world. As this has happened we have seen the emergence of a number of certifications beyond Scrum.
Certainly Agile can be considered to have “crossed the chasm” in terms of adoption as a way of building software today. Various studies and investigations indicate that most organisations are now using Agile in some or all of their software development projects. One report I saw (from Gartner I believe, but I can’t remember the exact reference) stated that “the majority of software projects will be built using Agile in 2012″, and 70% of the Fortune 1000 companies are using Agile for at least some of their software development.
Unfortunately, many of the Agile adoptions we see out there are dubious, to say the least. Organisations and teams “doing Agile” rather than “becoming Agile”. The difference is important, “doing Agile” is often associated with picking a few of the Agile practices (like selecting dishes from a buffet, pigging out on some and completely ignoring the greens) and expecting teams to apply them without understanding how they interact to deliver customer value.
Sometimes the set of practices chosen can help improve some aspects of the software development process – adopting TDD and automated unit testing will result in fewer defects in the code base, but won’t ensure that the team builds the right product. Far worse are “Tragile” implementations where there is a belief that Agile is an excuse to drop disciplined practices in favour of the new way of working – I’ve seen the team who were told by management that they no longer need requirements, just having User Stories is enough so hurry up and build the product, then they were unhappy that the delivered product didn’t meet the customer’s needs.
“Being Agile”, on the other hand, is like preparing a 12-course degustation meal carefully pairing each course with the appropriate wine. It is hard work – it requires disciplined approaches and a deep understanding of how the simple rules based on the Values and Principles of the Agile Manifesto must work together to form a complex adaptive system where self-organisation and emergent behaviours can happen. It is in these organisations and teams where you see the true benefits which can be achieved from Agile adoption – significantly reduced time to market, measurably improved customer satisfaction, massive reduction in defect counts, greater engagement and staff retention, the real joy in work and increased return on investment.
The questions for us at Software Education were “do our customers care about certification”, and having received a resounding “Yes” to that, which certification should we offer?
We examined the available options and settled on the newly formed International Consortium for Agile (ICAgile). We feel this organisation has credibility; it is the brainchild of Alistair Cockburn who truly is one of the founding fathers of the Agile movement, it is based around a model of learning that relates to how adults gain mastery in a subject area, and it is designed to be inclusive and comprehensive of the disciplines that go into building good software.
ICAgile certification is offered at three levels, modelled on the concepts of progressive skills acquisition from the martial arts – shu-ha-ri.
1) A foundation certification that says you know the language of Agile and understands the values and principles that underlay the approaches, as well as how the various practices work together to deliver value to our customers. This certification does not pretend that you are good at your job, only that you understand the values, principles and practices of Agile projects.
2) Having gained an understanding of the foundation, there are specialist learning paths that cover the variety of skills needed on a project – technical design and writing code, analysing and representing customer needs, testing and validating the product throughout the lifecycle, leading and guiding teams and coaching others to help them achieve the best results. This certification requires that your experience and knowledge extends beyond a single skillset, as Agile teams need cross-functional skills, and that others will attest to your competence.
3) To be acknowledged as a Master Agilist, you need to show a deep understanding of how Agile projects and teams work, and be able to prove that understanding in a practical hands-on working environment under the eye of existing masters.
Those who have studied the crafts will recognize this learning pathway as apprentice, journeyman, master, and this is quite deliberate.
The inclusivity of the ICAgile approach is shown in the way the learning objectives for the pathways have been developed. The definition of what participants need to learn was not devised by the founders of ICAgile, but rather in collaboration with a broad range of people from around the world, and there is no expectation that these learning objectives will remain static. As new ideas take hold and are proven to be useful they will be incorporated into the learning objectives for the various streams.
Two of us at Software Education have been involved in defining the learning objectives in our areas, myself in the Business Analysis and Value Management stream, and Sharon Robson in the Software Testing stream. We can attest to the robustness of the debate and the level of careful thought that has gone into building the learning objectives.
The first ICAgile certified course that Software Education is offering is the new Agile Fundamentals course – a three-day deeply immersive, experiential course which covers all the learning objectives of the ICAgile foundation, certifying successful participants as Certified ICAgile Professionals, but more importantly giving participants a deep understanding of how to successfully “Be Agile”, not just “Do Agile”.
In the future, we are looking to align more and more of our courses with the ICAgile learning objectives – not because of the certification, but because they provide a solid guideline to what people need to know to be effective in the different disciplines.
The pathway to mastery has been designed, are you coming on this journey with us?
Posted by Shane Hastie