Talent Development Centre

Tag Archives: agile

All Talent Development Centre posts for Canadian technology contractors relating to Agile.

Scrum vs Kanban (Infographic)

As we approach the holiday season, you need to start preparing yourself for those heated arguments that are sure to come up at office parties and family gatherings — one of the more common being the age-old question “Scrum or Kanban???”

While Kanban has been around since Toyota introduced it, it only started gaining traction in 2004, nearly 20 years after Scrum gained its popularity for software development. Today, both are great approaches to product development and different independent contractors feel strongly about their preferred one. Do you have a preference? If not, check out this infographic from kanbanize. The source does make it a little biased, but there is still some helpful information if you’re working to sort the differences between the two.

preview_kanban-vs-scrum-inforgraphic

IT is No Longer Just About Technology

Brendhan Malone By Brendhan Malone,
Vice-President, Central Canada at Eagle

IT is No Longer Just About TechnologyAs explained in this recent article from Dice, the marketplace for IT contractors and technology employees is changing at a pace similar to that of technology itself. With many of the “heavy lifting” IT jobs having been outsourced either on or off shore, the IT employees or contractors that remain in high demand are those with both technical and business capabilities.

What does this mean?  In order to add the value companies are looking for, prospective employees and independent contractors need to be able to both understand and communicate the business objectives of any IT activity.

The Agile framework is being implemented in more and more large organizations and communication is a pillar of Agile delivery, as all disciplines work together and collaborate throughout the development process.  Agile delivery cannot be successful without all stakeholders clearly understanding the business objectives and able to communicate as such.

Furthermore, the concept of performing a single function on “an island” within an organization has either been outsourced, as mentioned, or become entirely a thing of the past.

How do you as a contractor address these changes?  Firstly, take the time to understand the big picture: What is the overall project objective, not just your piece?  Understand the company you are working for, their history, their results, their major projects and initiatives.

Most consultants today work with one or more staffing agencies.  Hold your recruiter accountable for as much information as possible on each particular job opportunity.  This information will allow you to demonstrate your business capabilities and understanding as well as your valuable technical skills.

Keep up-to-date on the overall technology landscape. If you are in Telecommunications, know what the big 3 Telco’s’ major initiatives are.  If you have focused on the financial sector, know what major initiatives are coming from the big banks.

It is no longer possible to maximize your earnings and potential with technical skills alone.  All aspects of IT and business have become too interdependent.  Businesses rely more and more on technology every day as we know.  With this increased reliance comes a greater need for technology resources to understand business objectives and vice versa.

Ironically, the single most effective way to increase your business knowledge and communication skills… is a good old face to face conversation.

Garry Berteig Reflects on Being Agile in a Crisis

This post by Rachel Perry originally appeared on the Agile Advice Blog on August 24th, 2016

Talent Development Centre subscribers can get 25% off Agile training! Visit www.worldmindware.com and use promocode EPR-25-CSM-MV4A for Certified ScrumMaster courses and promocode EPR-25-CSPO-QE7X for Certified Scrum Product Owner courses.

Garry Berteig Reflects on Being Agile in a CrisisOn May 03, 2016 wildfires encompassing Fort McMurray, Alberta forced the evacuation of more than 88,000 residents, including many friends, family and associates of BERTEIG.

One such resident was Garry Berteig, a co-founder of OpenAgile, and long-time resident of Fort McMurray.

Recently, I had the opportunity to speak with Garry from his home in northern Alberta. He presents some meaningful insights into how living and working with an agile mindset helped him and his family move through the disaster with stability. The following articles shares, in his words, some highlights of his experience during and after the event.

BEING AGILE IN A CRISIS
By Senior Agile Coach Garry Berteig

Most of the time, when you are acting with agility you are sort of ready for change or turn in direction anyhow. You know what you have to do so your tasks are already in motion, your tasks are already moving towards “done”, not that you have your suitcase packed already but you already know what is the most important thing.

It’s the same for corporations. It’s just not so direct or life-threatening as this catastrophe was but for some companies catastrophe is a slow burn.

The actuality about what occurred, was quite different than the media reports. The media reports were at best simple, at worst a high-level notion.

Yes there was a line of cars, and they show a line up of cars [in the news] but it doesn’t tell you that some people were in one way or another in a state of calm because they are used to being involved in safety measure. That group was relatively calm.

There’s another set of people who were actually terrified and not able to be rational so they have to be handled carefully.

Then another group of people who were on the opposite extreme were kind of ‘having a good time.’ It was taking them away from their normal routines so they were making light of the whole situation. They were rolling windows down, playing loud music, giving peace-signs, stuff like that.

The real take-home point, having landed in Edmonton and being involved with people here is that the kindness, hospitality, generousity and sympathy that people revealed was amazing.

This is a feature that I share and have been sharing with other people who have also found the same thing. It’s been quite remarkable. Their private lives had an opportunity present itself openly. In my opinion, it represents a spiritual condition. Usually people hold that in to themselves and have no opportunity to express that. [They want to be kind, generous and helpful but keep it internalized.]

The government and non-profits have also been incredibly efficient and helpful. Because of all the other experiences with other catastrophes, their quick response to 90,000 people leaving Fort McMurray was remarkable. Within one week they had arranged for financial support for all those people. That to me is the material future of Canada. It is positive. The material and spiritual future of Canada is very great. And that is what I’ve seen here.

The other point is that before Fort McMurray was black-listed by the media but that has turned 180 degrees. Now people will realize the participation in this city from all over the country. The nation raised 1 million through the Red Cross.

Thankfully, not only is Garry and his family safe and well but all other friends and associates are also settling back into their routines and beginning the long journey ahead of restoration and recovery.

***************************************************************

UPDATE: August 03, 2016 – Unbelievably, epic flooding has now hit Fort McMurray, and in places the flood waters are damaging houses which had survived the fire. More updates will be shared as they emerge. Garry’s family is still doing well.

Web Development Jargon Decoded: Agile Scrums, Kanban and Waterfalls

Web Development Jargon Decoded: Agile Scrums, Kanban and WaterfallsThis post by Dennis Furlan first appeared on the Freshbooks Blog on June 1, 2016

As a web-development professional, you’re often dealing with clients and personnel who aren’t themselves in the field. They might have never worked within a web-development company before, or have little experience working with a web developer.

On top of that, web designers themselves — even those experienced in website development — may have worked in a web-design company where there was only one approach to custom software development and web design. If that’s the case, you might not be aware of approaches used in other web-development environments.

Whatever the case may be, as a web developer or website designer, you may not be as familiar with the basic terms of the profession as is ideal. Don’t worry, we’re here to help! With a Web Development Terms 101 refresher, we clarify the web-design terms you need to know.

Web Development Terms 101: Waterfall Versus Agile

First, there are a couple of web-design terms that essentially define the school of software development company or environment you work in. Back in the old days of software development services — let’s say back in the time when the Pong video game would have been considered leading edge — many software development companies would have used what’s called the waterfall model of software design. This is in contrast to a term that is perhaps more familiar to web developers today: the agile approach.

With the waterfall model, a more traditional, linear and predictable approach to software development is followed. Although the term waterfall may not be completely accurate, since it conjures up images of falling over the edge, it is a term that captures the essence of what these traditional development models do, which is to have a very structured work process in which one stage of software development is accomplished before the next.

As an example, you might have a web development model that consists of conception, design, code construction, testing, and deployment. The process only moves forward when a stage is completed. So, design can’t happen until conception, code construction until design, and so on. In fact, it’s a model of product development that dates back to the manufacturing model of decades ago.

The Challenge With Waterfall (aka Why Agile?)

However, in software and web development (just as with manufacturing), the traditional waterfall model has its flaws. It is rigid, can lead to backlogs, and, if one stage in the development process breaks down, can mean everything breaks down. To solve these challenges, more agile approaches deployed in the manufacturing sector, and in web-development companies, too.

With agile, the goal is as the name suggests: to achieve greater website-design productivity with a more agile approach to web design.

So, if we were to take the same example as above, instead of one linear process that starts with conception and ends with deployment, which is the case with the waterfall model, all the processes in an agile system — conception, design, code construction, testing, and deployment — can occur at the same time using flexible and interactive teams from start to finish. The advantages to this agile approach to web-design services include:

  1. Problems can be anticipated more quickly
  2. Decisions can be made to change direction in mid-course without major disruption to the larger endeavour
  3. No single process is beholden to another
  4. Everything gets done simultaneously, in a manner of speaking — meaning the project should be completed faster

With a web development company using this agile approach, there is less a reliance on tasks and schedules and a greater implementation of processes that incorporate various components of the chain. These processes can involve what is known as a sprint, which defines (in conjunction with customer feedback) the deliverables to be achieved within weeks, and not months. Sprints allows for better feedback from the customer and a more flexible delivery of the final product and service.

As much as it might be seen as trendier or more modern to be saying that you work in an agile web-design company, there really isn’t a right or wrong approach. It really is about assessing the client’s needs and how your own web-development company best meets them. With the waterfall approach, everyone is on the same page from start to finish. With agile, it’s a more flexible, improvisational process throughout. What works depends on the situation.

The Processes Within Agile: Scrum Versus Kanban

Now, what can confuse matters even further are web-design terms that make further differentiations in process and approach. Specifically, many web developers may be familiar with website-design terminology such as scrum and kanban. Well, these are essentially examples of the agile approach, and differ in some fundamental ways.

If there is one overriding differentiation between scrum and kanban it’s that, while scrum tends to be more structured and defined, kanban makes some of these same structures optional while keeping certain broader principles intact. This basic point of differentiation can manifest itself in the following ways:

 Scrum  Kanban
Focuses on specific processes from the outset Greater emphasis on broader goals instead vs specific tasks
Establishes cross-functional teams Cross-functional teams are optional
Workloads are often pre-determined Workloads are often defined as project is underway
Limits on work-in-progress and lead times are established Limits on work-in-progress and lead times are optional
Ideal for web-development companies seeking dramatic shift to the agile approach Suitable for web-development companies seeking a less radical upgrade to agile model

Meeting Your Client’s Web-Developer Needs

Again, is there really one website development approach that’s better than the other? Of course not. As always, it depends on your web development company’s ability to meet the needs of the client. In general, if your organization needs a dramatic shift towards agile, then scrum might better help establish specific structures. Alternatively, if the processes are already there, but in need of broad incremental improvements, then kanban might be the way to go.

Regardless of which web development terms you use, it’s always important to remember to match the organizational goals of your web development company with that of cherished clients seeking web-page design that meets their specific needs.

Refactoring and Business

This is part two of a two part series (Part 1 can be found here). The original article Refactoring: 4 Key Principles was originally featured on the Agile Advice blog by Mishkin Berteig.

Talent Development Centre subscribers earn 30% off Agile Training Sessions in 2016. Register here and use Eagle’s membership number BLP038YK7E

Refactoring and BusinessIn the Scrum Master and Product Owner classes that we teach, this topic comes up frequently: how does the business account for refactoring?  How do we “govern” it?  How do we make good decisions about refactoring?

There are a few principles that are important in helping to answer these questions.  All of these principles assume that we are talking about refactoring in an Agile team using a framework like Scrum,OpenAgile, or Kanban.

Refactoring Principle One: Keep It Small

Refactoring is safest and cheapest when it is done in many small increments rather than in large batches.  The worst extreme is the complete system re-write refactoring.  The best refactoring activities take seconds or minutes to execute.  Small refactorings create a constant modest “overhead” in the work of the team.  This overhead then becomes a natural part of the pace of the team.

Not all refactoring moves can be kept so small.  For example, upgrading a component or module from a third party might show that your system has many dependencies on that module.  In this case, efforts should be made to allow your system to use both the old and the new versions of the component simultaneously.  This allows your system to be partially refactored.  In other words, to break a large refactoring into many small refactorings.  This, in turn, may force you to refactor your system to be more modular in its dependencies.

Another common problem with keeping refactorings small is the re-write problem.  Your own system may have a major component that needs to be re-written.  Again, finding creative technical means to allow for incremental refactoring of the component is crucial.  This can often mean having temporary structures in your system to allow for the old and new parts to work harmoniously.  One system that I was working on had to have two separate database platforms with some shared data in order to enable this “bi-modal” operation.

Refactoring Principle Two: Business Catalysts

When is the earliest that a refactoring should be done? Not whenever the technical team wants to do it.  Instead, the technical team needs to use business requests as catalysts for refactoring.  If the business needs a new feature, then refactoring should only be done on those parts of the system that are required to enable that feature.  In other words, don’t refactor the whole user interface, just refactor the parts that relate to the specific business request.

Again, there can be exceptions to doing this… but only in the sense that some refactorings might be delayed until a later date.  This is tricky: we want to make sure that we are not accumulating technical debt or creating legacy code.  So, instead, we need to allow the technical team to refactor when they detect duplication.  Duplication of code, data or structure in the system.  A business request might impact a particular part of the system and the team sees how it might be necessary to refactor a large swath of the system as a result.  But, the cost of doing so is not yet justified: the single request is not enough of a catalyst, and the team can also choose a simple temporary solution.  Later, the business makes another request that also implies the same large refactoring.  Now is the time to seriously consider it.  It is now a question of duplication of another simple temporary solution. The business may not be happy with the extra expense of the large refactoring so the principle of keeping it small still applies.  However, the technical team must also be willing to push back to the business under the right circumstances.

Refactoring Principle Three: Team Cohesion

Teamwork in Agile requires high levels of communication and collaboration.  In refactoring work, teamwork applies just as much as in any other activity.  Here, it is critical that all members of the team have a unified understanding of the principles and purpose of refactoring.  But that is just the first level of team cohesion around refactoring.

The next level of team cohesion comes in the tools, techniques and practices that a team uses in refactoring.  Examples include the unit testing frameworks, the mocking frameworks, the automation provided by development tools, continuous integration, and perhaps most importantly, the team working agreements about standard objectives of refactoring.  This last idea is best expressed by the concept of refactoring to patterns.

The highest level of team cohesion in refactoring comes fromcollective code ownership and trust.  Usually, this is built from practices such as pair programming or mob programming.  These practices create deep levels of shared understanding among team members.  This shared understanding leads to self-organizing behaviour in which team members make independent decisions that they know the other team members will support.  It also impacts research and learning processes so that teams can do experiments and try alternatives quickly.  All of which leads to the ability to do refactoring, large and small, quickly and without fear.

Refactoring Principle Four: Transparency

In many ways, this is the simplest refactoring principle: the team needs to be completely open and honest with all stakeholders about the cost of refactoring.  This can be difficult at first.  Another analogy helps to see the value of this.  A surgeon does not hide the fact that care is put into creating a clean operating environment: washing hands, sterilizing instruments, wearing face masks and hair covers, restricted spaces, etc.  In fact, all of those things contribute to the cost of surgery.  A surgeon is a professional who has solid reasons for doing all those things and is open about the need for them.  Likewise, software professionals need to be open about the costs of refactoring.  This comes back to the main point of the first part of this article: hidden and deferred costs will still need to be paid… but with interest.  Software professionals are up-front about the costs because doing so both minimizes the costs and gives stakeholders important information to make decisions.

The challenge for business stakeholders is to accept the costs.  Respecting the team and trusting their decisions can sometimes be very hard.  Teams sometimes make mistakes too, which complicates trust-building.  The business stakeholders (for example, the Product Owner), must allow the team freedom to do refactoring.  Ideally, it is continuous, small, and low-level.  But once in a while, a team will have to do a large refactoring.  How do you know if the cost is legitimate?  Unfortunately, as a non-technical stakeholder, you can’t know with certainty.  However, there are a few factors that can help you understand the cost and its legitimacy, namely, the principles that are described here.

If the refactoring is small, it is more likely to be legitimate.

If the refactoring is in response to a business catalyst, it is more likely to be legitimate.

If the refactoring is reflective of team cohesion, it is more likely to be legitimate.

And, of course, if the refactoring is made transparent, it is more likely to be legitimate.

About the Author
Mishkin Berteig is the President and Co-Founder of Berteig Consulting Inc. He has been Mishkin Berteigtraining, coaching and consulting for organizations adopting Agile methods since 2001 and is committed to helping individuals, teams and organizations apply Agile methods. Mishkin is a Certified Scrum Trainer, and qualified to deliver OpenAgile and Agile Project Management training.  He has developed and delivered Agile training both in public and in-house seminars for over 3000 people in Canada and abroad. Courses have been as short as three hour intro-style and as long as five day boot-camp-style, and audiences have ranged from junior team members to senior executives. He has also assisted organizations of all sizes to make the transformation from traditional methods to Agile/Scrum methods (Extreme Programming, Scrum, Lean, OpenAgile).  Assistance includes Agile Engineering Practices, Agile teamwork, Agile project and product management, Agile management and executive management.

Refactor or Die

This is part one of a two part series. The original article Refactoring: 4 Key Principles was originally featured on the Agile Advice blog by Mishkin Berteig.

Talent Development Centre subscribers earn 30% off Agile Training Sessions in 2016. Register here and use Eagle’s membership number BLP038YK7E

Refactor or DieEvery software system that we build is inside a dynamic environment.  The organization(s) using the software are all in a state of constant change.  The people using the software are also constantly changing.  Due to this constant change, every software system needs to be adapted to the environment in which it is used.  Most of the time, businesses think of this constant change in terms of new features and enhancements – the scope of functionality that a system can handle.  Less commonly, businesses think of this change in terms of the obvious external qualities and attributes of the system such as performance or security.  But almost never does an organization, from a business perspective, think of the invisible qualities of the software system such as simplicity and technical excellence.

What happens when the business does not recognize those invisible qualities?  I’m sure almost every software developer reading this can answer this question easily: the system becomes “crufty”, hard to maintain, bug-prone, costly to change, maze-like, complex.  Some people refer to this as legacy code or technical debt.

The longer this state is allowed to continue, the more it costs to add new features – the stuff that the business really cares about.  It is pretty easy to see how this works – for someone who has a technical background.  But for those without a technical background it can be hard to understand.  Here is a little analogy to help out.

Imagine that you set up a system for giving allowance to your kids.  In this system, every week your kids have to fill out a simple form that has their name, the amount that they are requesting, and their signature.  After a few weeks of doing this, you realize that it would be helpful to have the date on the form.  You do this so that you can enter their allowance payments in your personal bookkeeping records.  Then you decide that you need to add a spot for you to counter-sign so that the paper becomes a legal record of the allowance payment.  Then your kids want extra allowance for a special outing.  So you add some things on the form to allow them to make these special requests.  Your accountant tells you that some portions of your kids allowance might be good to track for tax purposes.  So, the form gets expanded to have fields for the several different possible uses that are beneficial to your taxes.  Your form is getting quite complex by this point.  Your kids start making other requests like to be paid by cheque or direct-deposit instead of in cash or to be paid advances against future allowances.  Every new situation adds complexity to the form.  The form expands over multiple pages.  Filling out the form weekly starts to take significant time for each child and for you to review them.  You realize that in numerous places on the form it would be more efficient to ask for information in a different way, but you’re not sure if it will have tax implications, so you decide not to make the changes… yet.  You decide you need your own checklist to make sure that the forms are being filled out correctly.  A new tax law means that you could claim some refunds if you have some additional information… and it can be applied retroactively, so you ask your kids to help transcribe all the old versions of the form into the latest version.  It takes three days, and there is lots of guess-work.  Your allowance tracking forms have become a bureaucratic nightmare.

The forms and their handling is what software developers have to deal with on a daily basis – and the business usually doesn’t give time to do that simplification step.  The difference is that in software development there are tools, techniques and skills that allow your developers to maintain a system so that it doesn’t get into that nightmare state.

For a more in-deth description of this process of systems gradually becoming more and more difficult to improve, please see these two excellent articles by Kane Mar:

Technical Debt and Design Death

Technical Debt and Design Death: Part II

Ultimately, a software system can become so crufty that it costs more to add features than the business benefit of adding those features.  If the business has the capacity, it is usually at this point that the business makes a hard decision: let’s re-write the system from scratch.

I used the word “decision” in that last sentence.  What are the other options in that decision?  Ignoring the problem might be okay for a while longer: if the company is still getting benefit from the operation of the system, then this can go on for quite a while.  Throwing more bodies at the system can seem to help for a bit, but there are rapidly diminishing returns on that approach (see The Mythical Man-Month for details).  At some point, however, another threshold is reached: the cost of maintaining the operation of the system grows to the point where it is more expensive than the operational value of the system.  Again, the business can make a hard decision, but it is in a worse place to do so: to replace the system (either by re-writing or buying a packaged solution), but without the operating margin to fund the replacement.

In his articles, Kane Mar describes this like so:

It’s pretty clear that a company in this situation has some difficult decisions ahead. There may be some temporary solution that would allow [a company] to use the existing system while building a new product, [A company] may decide to borrow money to fund the rewrite, or [a company] may want to consider returning any remaining value to their shareholders.

In other words, refactor or die.

About the Author
Mishkin Berteig is the President and Co-Founder of Berteig Consulting Inc. He has been Mishkin Berteigtraining, coaching and consulting for organizations adopting Agile methods since 2001 and is committed to helping individuals, teams and organizations apply Agile methods. Mishkin is a Certified Scrum Trainer, and qualified to deliver OpenAgile and Agile Project Management training.  He has developed and delivered Agile training both in public and in-house seminars for over 3000 people in Canada and abroad. Courses have been as short as three hour intro-style and as long as five day boot-camp-style, and audiences have ranged from junior team members to senior executives. He has also assisted organizations of all sizes to make the transformation from traditional methods to Agile/Scrum methods (Extreme Programming, Scrum, Lean, OpenAgile).  Assistance includes Agile Engineering Practices, Agile teamwork, Agile project and product management, Agile management and executive management.

What You Need to Know About Agile Certification

Colin Montgomery By Colin Montgomery,
Director, Private Sector Services

Much of my day is spent discussing trends in the IT industry with clients and people in our resource network.  The hot topic these days is Agile ceWhat You Need to Know About Agile Certificationrtification. “Which certification is best and what is the value of certifications” tend to be the questions I’m asked.

While it’s beyond my scope to judge the value of the certifications themselves, from a staffing perspective, I can comment on some trends I see emerging.

First off, some type of Agile certification has value for anyone, including people who work on the business side of an organization which has adopted Agile who may only occasionally interact with IT.   Through the analysis phase of a technology project there is inevitably interaction between business and technology.  There is value in those who embrace and participate in the increased speed to market that the Agile process can contribute to and there is value in those who bridge the chasm that often exists between business and technology.

Program and Project Managers also ask me if they should get certified and my answer is a definite “yes”.   While you may no longer be close to the software development or network integration process, the assumption is that you will be providing some oversight to those processes and if they are being completed within the Agile framework then you should know the language and cycles of that process.  If you are a senior individual who has worked with the waterfall methodology for years, then your new-found knowledge of the Agile processes can help contribute to a project delivery framework that uses both where appropriate, for example. From an even simpler perspective, many of the PM roles we work on require some kind of Agile certification so in this world of key-word searches, you should have something on there.

As I mentioned earlier, while it is beyond my scope to comment on the value of specific certifications, I do suggest that anyone in IT realm should get some kind of baseline Agile certification as soon as they can especially if you anticipate entering the job market soon.

CSM (Certified Scrum Master) appears to be the most prevalent and would likely be used as a common term for keyword searches.  My understanding is that the CSM requires around 16 hours of course work and a multiple choice test that takes about an hour.

Another certification that is generating a lot of discussion is the PMI-ACP(Agile Certified Practitioner).  It requires more time and effort but seems to be emerging as a strong preference for those leading technology projects.

The discussions I’m having these days around Agile certification remind me a lot of the conversations I had a few years ago regarding PMP certification and I’m saying the same thing to those who are reluctant that I did back then.  It’s not going anywhere so you might as well get on board or risk being left behind.

The Importance of Certifications for IT Professionals

Brendhan Malone By Brendhan Malone,
Vice-President, Central Canada at Eagle

The Importance of Certifications for IT ProfessionalsI recently came across an article from Global Knowledge listing the 15 Top-Paying Certifications for 2016. It brings some very good discussion points to light.  Should we certify? What are the most marketable certifications?  What certifications look to have future relevance?  The article is especially useful as it ties a monetary figure to each certification.  Although many other variables exist in that figure, it gives us a good idea of the relevance and demand of the skill set and certification.

To certify or not to certify… that is the question

The answer in most cases is yes, yes, and yes.  This is true for both full-time IT professionals as well as independent contractors.

For independents contractors, the goal is for your consulting business is to be seen in the marketplace as a trusted partner.  Certifications go a long way in establishing credibility in your business offering. We hear the term “building your brand” often in today’s business environment.  Part of any strategy of building your brand is building trust in your capabilities through experience, references, and… certifications. Being current and up-to-date in your certifications shows that you, as an independent contractor, are aware of the current and relevant technologies, and that you are invested in being as up-to-date as possible in the ever changing marketplace.

For full-time resources, it is absolutely critical that prospective or current employers know that YOU are invested in your career and advancement of your skills. A mistake employees often make is that they are waiting or expecting their employer to initiate skill development, training and certification discussion.  While some employers do a better job than others with professional development, the onus is on YOU to initiate these discussions and formulate a strategy for development.

So which certification is right for you?

The answer to that question lies in your area of expertise, but the list in the article referenced above can surely help you see your best options. One certification that I did not see on the list, and perhaps it is because its popularity has been more recent, is that of a Certified Scrum Master.  Thousands of companies are moving to an Agile or Agile-based methodology and this certification becomes more valuable by the day.  For more information on the Scrum certification, have a look at Scrum Alliance and the Agile Advice blog.

Do you have any certifications or are you working towards one right now? Do you have any recommendations for a new IT contractor looking to improve their competitiveness? Please leave your suggestions in the comments below.

If Your Up-Front Planning is Measured in Weeks, Then a Lean Startup is Going to Eat Your Lunch

Talent Development Centre subscribers earn 30% off Agile Training Sessions in 2016. Register here and use Eagle’s membership number BLP038YK7E

This post by David Sabine was originally posted on the Agile Advice Blog on October 30th, 2015. Title inspired by Michael James… see below.

If Your Up-Front Planning is Measured in Weeks, Then a Lean Startup is Going to Eat Your LunchOne of the most powerful assumptions built in to Agile methods is that we learn by doing — that our learning, our planning, our problem-solving, and ability to mitigate risk is enhanced when planning is performed inline with active development and in the context of deliberate experimentation.  Scrum, for example, is based on empirical process control theory which means that we make decisions based on what is known.

One of the most common pitfalls we see among organizations trying to “adopt” Agile is excessive pre-planning — their assumption being that we can decide by planning, learn by planning, or mitigate risk by planning.  This sometimes manifests as an anti-pattern that people call “Sprint Zero” — a signal that an organization misunderstands Agile methods fundamentally.  More importantly, a signal that the organization may incorrectly perceive Software Engineering — or any team-based work — as predictable

If your organization injects a “Sprint Zero” or a planning phase (that is measured in weeks rather than days or hours) ahead of the creation/development of real product, then these two posts are of interest to you:

michael-james-comment

Agile Planning in a Nutshell

By Mishkin Berteig
President, Co-Founder of Berteig Consulting

Talent Development Centre subscribers can get 25% off Agile training! Visit www.worldmindware.com and use promocode EPR-25-CSM-MV4A for Certified ScrumMaster courses and promocode EPR-25-CSPO-QE7X for Certified Scrum Product Owner courses.

This post was originally posted on the Agile Advice Blog on August 21st, 2015.

Agile Planning in a NutshellAgile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans.  However, many teams desire a long-term plan.  This can be thought of as a roadmap or schedule or a release plan.  Agile planning helps us build and maintain long-term plans.

Agile Planning Process

The steps to do this are actually very simple:

  1. Write down all the work to be done.  In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
  2. Do some estimation of the work items.  Many Agile estimation techniques exist including Planning PokerThe Bucket System,Dot VotingT-Shirt Sizes.  These tools can be applied to many types of estimation.  There are three kinds of estimation that are important for Agile Planning:
    1. Estimating relative business value.  Usually done with the business people including customers and users.
    2. Estimating relative effort.  Usually done by the Agile team that will deliver the work.
    3. Estimating team capacity.  Also done by the Agile team (this is sometimes called “velocity”).
  3. Create the long-term plan.  Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work.  (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.)  Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.

Agile planning allows a team to update estimates at any time.  Therefore, the techniques used above should not be thought of as a strict sequence.  Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated.  Scrum refers to this ongoing process at “Product Backlog Refinement”.

Principles of Agile Planning

In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:

  1. Speed over accuracy.  We don’t want to waste time on planning!  Planning in and of itself does not deliver value.  Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
  2. Collaborative techniques.  We don’t want to be able to blame individuals if something goes wrong.  Instead, we create safe estimation and planning techniques.  Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
  3. Relative units.  We don’t try to estimate and plan based on “real” units such as dollars or hours.  Instead, we use ordering, relative estimation and other relative techniques to compare between options.  Humans are bad at estimating in absolute units.  We are much better at relative estimationand planning.

About the Author
Mishkin Berteig is the President and Co-Founder of Berteig Consulting Inc. He has been Mishkin Berteigtraining, coaching and consulting for organizations adopting Agile methods since 2001 and is committed to helping individuals, teams and organizations apply Agile methods. Mishkin is a Certified Scrum Trainer, and qualified to deliver OpenAgile and Agile Project Management training.  He has developed and delivered Agile training both in public and in-house seminars for over 3000 people in Canada and abroad. Courses have been as short as three hour intro-style and as long as five day boot-camp-style, and audiences have ranged from junior team members to senior executives. He has also assisted organizations of all sizes to make the transformation from traditional methods to Agile/Scrum methods (Extreme Programming, Scrum, Lean, OpenAgile).  Assistance includes Agile Engineering Practices, Agile teamwork, Agile project and product management, Agile management and executive management.