waterfall vs agile

Agile IS NOT Scrum!

Posted on by

agile-is-not-scrumThere are certainly many misconceptions that occur with having to implement agility within the organization. The issue becomes even more compounded when non-agile practitioners speculate about what Agile is or for that matter what their idea of what it should be. In our example, this kind of speculation can present a sort of revolving door phenomenon whereby those who are familiar with Scrum, use it to refer to Agile interchangeably. Admittedly, Scrum is a large part of Agile when referring to it holistically, but Agile is not Scrum. However, we can derive some values from Scrum and say that they are synonymous with Agile values. What tends to happen is that many people believe that if they are doing Scrum, then automatically they are Agile. There’s a very fine line to that supposition, but it’s not always entirely true.

Part Of The Whole Doesn’t Necessarily Mean You Are All Of The Whole

For the most part, implementing a part of the whole doesn’t necessarily mean you are all of the whole. As an example we can use the idea of electricity. If some parts of a car (i.e. radio, window system, pumps, battery) are electric, would you say that your car is an “electric” car? Not likely. Even when we do refer to electric cars that are motorized by electric power cells alone, the car isn’t entirely electric per se. This comparison although not an exact representation of the differences in Agile or Scrum, hopefully can give you the level of complexity in the assumption of either one for another.

Agile Is Not Just A Process

For further clarity, there are other mechanisms of Agile in perspective, there is also a mindset and value-driven aspects that should be accompanied with it, not just a process. There’s also other methodologies and processes that can be included or can be complimentary to Scrum (i.e. XP, Kanban, TDD, ATDD) that make a more solid Agile implementation possible. That is not to say that it’s an “all-or-nothing” situation. Further to this we have what is considered to be the Agile guidelines, also known as the Agile Manifesto consisting of 4 values and 12 principles. When speculation and discussion occurs about what Agile really is, very seldom does the conversation include what is mentioned in the manifesto. However, more often, the concept of implementing a Scrum process does. This is where the clarification about those assumptions or beliefs, is very important to distinguish before it’s too late, whereby the decision takes place and is built on a preconceived false notion of Agile.

Agile Expectation And Implementation

Getting the above points out in the open early is not only to assure successful Agile expectation and implementation, but also to bring a more positive light to what can sometimes bring “failures-as-fact.” By that we mean that there are many who have attempted implementing Agile in the workplace, and used a “not-so-complete” method or process into effect. That is to say, they thought they were putting an Agile methodology (or in certain cases what they thought was Agile) in place, then saw it fail, and then concluded “Agile doesn’t work” despite the other flaws.  There are certainly instances where Agile really doesn’t work, or perhaps it isn’t the best solution for your organization, politics and bureaucracy aside. Agile isn’t the cure-all solution to all your organizational woes but can definitely be more fun! Even when it’s not a good match for the organization, not implementing Agile is perfectly fine, it’s not a must, and further to that, it’s not a religion (although it sometimes is perceived as such).

Major Hurdles to Agile Adoption in Government Organizations

Posted on by

major-hurdles-agile-adoption-government-organizationsDespite what you’ve heard on the news about the federal debt, many federal, state, and local government agency budgets have been flat or declining for several years. Add in inflation and other cost increases, and these agencies are constantly being asked to do more with less. For the IT departments, this surely means they’ve made the transition to lean, mean, Agile teams, right? Well, no. But there are some good reasons for that.

Responsible Spending and Risk-Aversion

Government organizations usually have budgets that are determined by politicians and other actors outside the agency itself. Unlike companies that can expand budgets through increased revenue and profitability, government agencies need to justify budget requests by showing they have a responsible track record deploying their budget to meet their mission.

Tax payers don’t want the government making reckless decisions with their money. As a result, government organizations routinely make decisions that can be justified as responsible, risk-averse, or “safe” – even if those decisions are not the most efficient or cost-effective. I’ve heard it said that nobody has ever fired a government employee for using Microsoft Project on an IT initiative. In an environment like that,  a half-century old methodology like Waterfall – or a century old tool like Gantt charts – would be seen as preferable to newer methodologies that are not well understood to business or political stakeholders.

Delivery Dates vs. Sprint Cycles

Government IT solutions and systems are often the result of new laws or regulations, and have a defined time period in which they must be implemented after the new law is passed. Just like the adage, “requirements may be vague, but the software will be specific,” laws may be vague, but the regulations must be specific, and the software that implements them must be even more specific. Elements like complex business logic and multiple system interfaces cause managers and business stakeholders to ask for lots of documentation to prove that the system was built correctly.

When a new law mandates implementation by a specific date it creates an anchoring effect, that the system needs to be “done” by that date. Briefing senior government officials or even legislators on sprint velocity and burn rates is a much bigger challenge than providing dates and percentages. Even if, in the end, delivering the most valuable 80% of a solution on time should be preferable to delivering 100% of a system after a 1-2 year delay.

Software and Tools

Another reason no one in government ever got in trouble for managing an IT project with Microsoft Project is because it is already on the list of pre-approved software for use that nearly every agency maintains, in one form or another. Hardware and infrastructure requirements are a common consideration, as are licensing costs. But security concerns are an increasingly big reason why software on pre-approved lists keeps getting used instead of newer or better products being adopted.

Getting software tools approved for use at a federal agency means completing a thick stack of paperwork. It also requires a champion to spearhead the process, work with Help Desks on administration and conducting training. This means longer-term commitments to tools than in the private sector, and that larger companies with established products get used more often.

End User vs. Customer

Until recently, most end users of government IT systems were employees of that agency, so there was little conflict in seeing the end-user as an internal customer. As the internet has proliferated, more businesses and individuals are interacting directly with government IT systems: submitting applications and appeals, self-registering or updating information, or just searching for general information on a government website or portal. These external end users, or government customers, present a unique tension when designing systems for them.

While “the customer is always right” is a great motto for many private businesses, government agencies need to walk a fine line with that approach. They run the risk being too accommodating or “too cozy” with the people and businesses they regulate, and can erode trust that the government agency can regulate or monitor effectively.

Tight budgets, pre-defined timelines, and the need for some agencies to keep end users at arm’s length make it easy to de-emphasize agile principles like personas, end user demos, and usability sessions.

Contributing Author

David Pradko is a project manager and certified business analyst, who has worked with over a dozen government agencies to design and implement IT solutions. He as also appeared at the IIBADC’s Business Analysis Development Day and on Federal Tech Talk radio to discuss Agile in the federal government.

You can follow David on Twitter at @DPradko

[Image courtesy of Sira Anamwong at FreeDigitalPhotos.net]

How an Agile Approach Boosts the Value Cycle

Posted on by

how-agile-approach-boosts-value-cycleWhen it comes to team and company performance, many old-school thinkers and business-people look to how they can cut costs. Not their fault, but to some this is the only way they can leverage their stagnant knowledge, instead of taking on an agile approach and promote increased learning. This is likely where some are labeled as “the banker” or “the accountant.” There is recent evidence that shows if we perform on both sides of the finance and marketing fence, there is a higher level of progress and efficiency overall on spending, innovation, and revenue.

Conflicting Views: Cost Cutting vs. Value Creating

There are two strategic views that play within this spectrum; either cutting costs or creating value. Cutting costs creates the concept that there is a finite source of value or income that must be compensated for. Creating value on the other hand, breaks the barrier of thinking there is a cap on source of wealth and ideas. Certainly anything to be created requires that costs be incurred, but that is not to say we must limit investment if all the signs say GO!

Cause and Effect of the Value Cycle Explained

This brings us to the traditional vs agile project standard. When you look at a traditional project, the premise is set at the beginning of the project that it will have a finite timeline and budget. In an agile project you typically don’t have these restraints because the primary concern is about product and how to build value into it. All else if done properly will generate an infinite level of return. Why? Because a product being developed in an agile environment has the implicit expectation that with time there will be more to learn about the market, product composition, and technology that will allow for improvement. Reduced cost is a byproduct of the value cycle, since there’s usually a way to produce something with higher durability making it less prone to defects and complaints. This in turn satisfies the market and creates more demand and increased prices. Volume will also increase, and as we know that also drives down the maintenance or per unit costs.

Value Cycles Are Not Meant to be Broken

The value cycle never ends, hence why typically we look at an agile project as infinite as well. Actually the term “project” can be seen as a sort of oxymoron statement when putting words “agile” and “project” together. But that is for you and your peers to debate. When we look at the constituents of the value cycle right from the beginning where we determine requirements all the way to market release, maintenance and feedback, we can see very clearly that the market isn’t picky about how a product with unique features will look like at first sight. If someone claimed that a time-machine would take up the space of a city block, many would not be concerned. They would still look to use the product and would probably line up along a few city blocks to be the first to use it. This example may be a little far-fetched, but it is used to drive the previous point into context.

Why re-iterate?

As you can see value cycles and agile are very closely tied. They are based on an iterative process. If you believe you understand a concept upon the first try, there is a very high likelihood you missed a few points. If you take the first attempt, you may be successful, or you may not. However you took the first step, and there should be no reason to stop there. There can always be better, there is never any reason to stop improving.

[Image courtesy of Idea go at FreeDigitalPhotos.net]

 

5 Important Agile Interview Questions

Posted on by

5-important-agile-interview-questionsIf you are looking to recruit someone new in your company whether it’s for a new Agile implementation, or to replace someone who left, it’s important to get specific Agile interview questions asked up front during the recruitment and selection process.

Below we’ve outlined some basic yet relevant questions that you can ask a potential candidate, and gauge whether or not they are going to be a good fit for your department, team, or organization. That is not to say that your candidate should answer all of them correctly to be considered the perfect member to add to your team, but they should be within some level of understanding on why these questions are being asked.

1 – What does Agile mean to you?

For this question,  you should be looking for closely related Agile principles and values. It’s important to see how close your candidate can get to mentioning and explaining those values of:

A. Check whether your candidate is referring to how they like to interact in groups, looking to share ideas and solutions while promoting team building and servant leadership. If they tend to emphasize the processes and tools, this might not be such a bad thing but you should try to steer them into more group dynamic and group transparency based topics. If they don’t respond or get sidetracked to following orders and making sure everyone in their surrounding work environment must conform to process, this might be a less suitable candidate. However this is not the only basis on which to make your decision.

B. Many who try to impress in an interview, tend to throw ideas out of which documentation they would create and use throughout an agile project. It’s important to see if your candidate sees the value of delivering a working product. If they are the type of person that is trying to make sure everything works around the product except for the actual delivery of the product as necessary, it’s important to see if they are making this distinction.

C. If your candidate is more concerned about how many contracts they can get out of the customer, they might not understand the importance of the other aspect of Agile values which is to try to gain as much customer collaboration as possible. You wouldn’t want interactions with the client to be about how to draft a new contract every step of the way. Remember it’s the soft stuff (people skills) that’s the hard stuff, so your candidate should be able to demonstrate how they are able to engage the customer into problem solving discussions and come to mutually beneficial agreements.

D. If your candidate seems to be more concerned about project plans and gantt charts, they may be stuck in a waterfall mindset. These plans in an Agile setting are a distraction to actually executing the process of developing actual product. For this you should be trying to see if your candidate is looking solely to write-up a plan and make sure everyone follows it (command-and-control) vs. being able to point out the inherent importance of having a team self-manage and create a product based on prioritized features that a market is ruling as important for ROI.

2 – What types of Agile processes have you implemented before?

With this question, you should be able to get the candidate to point out if they’ve actually implemented Agile methodologies whether they are Scrum, XP, Lean, etc.. Key words that you can look for are those found from the beginning to end of the cycles. Words like Sprint Planning, Kanban Board, Burndown Charts, Retrospectives, etc.. You should be able to check and see whether they have an understanding of the ceremonies and events that occur through iterative cycles. More importantly, they should be able to point out why those processes exist and how they fit together to make a fully Agile environment possible.

3 – What is your idea of an Agile mindset?

The character and personality of your candidate fundamentally must be a good match to the agile mindset if they are to practice Agile. Common sense, right? however you might come across some who think they know what it means to be Agile but portray a completely different mindset. You may want to have a look at our other related articles that shed some light on what qualities an Agile Mindset has (or does not):

4 – How often must Agile be practiced during a project?

The answer to this one is simple: at ALL times! If your candidate starts to mention which aspects of agile should or shouldn’t be implemented, as if to compare switching it on or off like a light switch, this person may not actually understand the importance of synergies built over time through agile principles. This question is best answered in a holistic overall “outside the box” sense. Agility is not to be pulled apart and peeled only for certain parts and principles. This leads us to our next question.

5 – Can Agile be tailored?

This is a very important question as the candidate should be able to read between the lines. In practice it’s well-known that you should not be tailoring Agile right from the start unless you have many years of Agile experience. Many of the reasons why Agile fails, is because it is tailored to fit another mold, i.e. trying to fit Agile into Waterfall, and this is where false beliefs about the effectiveness of agile come in to play. Your candidate should be able to respond with a “yes, but…” type of answer. From there they should be able to point out that tailoring is not ideal, and that it would take place perhaps after multiple iterations and sprints, where the agile team notices certain events or processes that aren’t working well for them. This would usually be coming from the Sprint Retrospectives and observed in each successive retrospective to see whether they’re continuously improving or not. This makes the tailoring process more safe and tuned to the team’s needs.

[Image courtesy of Ambro at FreeDigitalPhotos.net]

 

5 Ways to Recondition a Waterfall Mindset to an Agile Mindset

Posted on by

5-ways-to-recondition-a-waterfall-mindset-to-an-agile-mindsetThe hardest part about attaining an agile mindset is undoing the beliefs and experiences of the past, especially if they were set over years and years of performing under a waterfall project methodology. Many would agree they had would have rather just started off with agile right from the start, instead of now realizing that experience must be undone. But like the expression says “better late than never.” Those who now have their eyes open to the benefits of adopting an agile mindset know there is no turning back. Or maybe that’s not as easy as it may seem. Undeniably, we are always influenced by our past experience and reprogramming our mindset to challenge our waterfall vs agile beliefs can come into play at any time.

Here are 5 ways you can recondition or progress toward an agile mindset:

1 – Keeping your priorities in check

If there is one thing that a waterfall methodology makes us lousy at is practicing our priorities. Since in waterfall we rely on a project plan with features set at the very beginning while expecting few changes later on, we lose the sense of why we are developing features later on that we no longer need. You may still see this in certain instances in agile project whereby the client still asks that all the original scope be delivered by the end of the timeline even when they may realize there no longer is any value to having some of those features. With an agile mindset all stakeholders would better understand that the project is a success as long as the prioritized features (not necessarily the entire product backlog) were developed within the agreed timeline.

2 – Knowing the difference between variable and fixed timeline

Referring to the previous point, in waterfall we agree on a timeline that we then may need to extend if there were any delays or unforeseen gaps that occurred. In agile we can fix the timeline if all stakeholders agree to priority of the features that they would like to have implemented. If all the top priority features are implemented by the end of previously determined set of sprints, it very likely will not need to have the timeline extended. That would also allow everyone to walk away with confidence knowing that the most important features were implemented. This basically means you need to adopt the concept of a fixed timeline and variable scope from an agile mindset, vs the fixed scope and variable timeline concept from a waterfall mindset.

3 – Avoid mixing project Gantt charts with Sprint and Kanban boards

Some of us might be tempted to report to many stakeholders and provide multiple types of reports in general. This could be internal auditors, PMO, upper management, etc. What you need everyone to realize is that there is no need to report in so many ways. In waterfall methodologies we tend to use “unlean” processes that give rise to the tendency to send a different report to each stakeholder in the hopes that everyone is reading them thoroughly. The truth is, some of these reports may be so complex, that most will look at them without a critical eye, only to be surprised that the report had raised many risks that surfaced. This is where having an agile mindset would come in handy. Mostly all stakeholders including the agile team are concerned about progress and the rate of progress. Keeping it simple with the use of Kanban or Sprint boards, and providing easy to read information radiators like Burndown, Burnup, or Cumulative flow diagrams will give a quick and informative idea on where it all stands.

4 – Dedicate yourself to agile training in all forms

We should not just learn about agile methodologies and claim we know all there is to know. Agile working tools evolve over time and it’s important to keep your ear to the ground on what the latest developments and ideas are from the industry experts and peers. Simply having a discussion with colleagues that have similar interests in agile implementation is a start. But as you would notice there are many other means to sharpening your agile mindset and agile tools. Participating in regular industry forums, conferences, agile training courses and annual tours can be highly beneficial and open your eyes to some concepts that were not previously discovered. Also picking up some books on agile, and reading a few from time to time will make sure you are feeding your way to improving your day-to-day ideas on how to promote and implement agile in your immediate work environments. Finally the scrum master role should be well instated, at some times with the help of agile business coach on board with your team. The agile coach in particular can gauge and see what can help improve what may already be in place, and furthermore stimulate ideas and get everyone elevated to an agile mindset.

5 – Keep asking yourself why certain processes and values have been adopted into the agile methodology

There are some in the industry that have a skewed idea of agile. Mainly because it’s something they may have heard someone else talk about and it just may seem to be a common buzzword. Those with a waterfall mindset may just think agile is a process, and will treat it as such. This will give rise to even more issues, as they may try to put sprints into place, and not really knowing why they are used in the first place. For instance, they might not actually believe in delivering anything beginning with the first sprint, although technically that should be possible. Also the duration of the sprint should be determined on how risky or how much change in the priority of the backlog items you expect to have. The main point here is to always be asking why certain processes exist and why they would be beneficial to the overall methodology. The other side of the coin is that some will implement agile in an environment where it isn’t even necessary, “if it ain’t broke, don’t fix it.”

Bringing these tips into consideration will help alleviate the built-in or innate experience that many of us have, especially if coming from a waterfall mindset. Also to be considered, is that nobody can switch on to an agile mindset overnight by reading an agile book or attending an agile conference. However, continuous learning, coaching and mentoring agility will certainly build on it.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

Bringing Continuous Improvement to Project Methodologies

Posted on by

To those who have never seen agile at work, it would seem a bit odd to think of implementing it at first. Most people would see the vast levels of acceptance while bringing continuous improvement to project methodologies and think it was literally impossible to put into practice. But that is exactly what Agile is, practice. We live in an imperfect world, but we also have come to the belief that “practice makes perfect.” We’re not sure if that expression became so popular because it rolled off the tongue so well, or because practice really does make things perfect.

Perfection is unattainable, but reaching perfection is attainable. Typically when we’re practicing anything whether it be a sport, hobby, or process, we come to realize that we have a tendency to do it better and better every time we do it. Upon completion we use expressions like “note to self” in order to be sure we don’t make the same mistake again the next time. Or vice versa, we make sure we try another approach that is slightly different. It is exactly this line of thinking that fuels innovation. Much in the same way, this is how Agile project methodologies became what they are, bringing speed, synergy, and continuous improvement through regular practice.

Why Tailoring Agile Impulsively is Not Recommended

bringing-continuous-improvement-to-project-methodologiesAs some will find out eventually, we will not likely have a truly perfect product by the end of the first sprint, and there probably will be some revisiting or refactoring later on. However, with the use of multiple sprints, the team is aware that there will be goals to practice constant improvement of the existing processes along with a learning curve with each iteration. Whether it be the result of bug-fixing, improved design, or better material for a longer lasting product, it is that very system of agile project methodologies that allows increments to be built upon with regular feedback. As an example we can refer to the much ignored and under-practiced Sprint Retrospective. As there might be a sense of time limitations, to get things closed off and ready for delivery at the end of a sprint, some teams and stakeholders will make the sacrifice of skipping the retrospective to do what is thought to be more productive completion work. This is in fact a huge sacrifice, since the habit of skipping the retrospective in itself will wipe out the need or perceived need to do one for any future sprint.

An instated workflow process that does not leave time for a feedback loop, will likely leave one out for all future workflows. When this happens, danger presides and can only be undone when someone with a persistent agile mindset (likely an agile business coach or scrum master role) attempts to inform everyone that it needs to be added in. As you will likely notice, the “swimming against the stream” effect will come into play. It will be met with much resistance to change as we know most groups are prone to. It also will be met with much discouragement and heartfelt and time-wasting debate since there will be many who will be on both sides of the fence.

Setting the Record Straight

This makes the point, agile project methodologies, principles, and mindset are in place to function like an entire working organism, the events that are meant to take place are much more effective when they are all in plugged in. If they are removed or tailored, there has to be a highly experienced agile working team with an experienced agile coach that could pin point the possible downfalls of removing any aspect. Further to this, the highly experienced team would need to come to the agreement that if the foreseeable pitfalls were to occur, the missing pieces will be added back in, and with certainty of knowing that the pitfalls are being caused by the tailoring process itself, much like “trial and error” in experimentation. If the agile team roles are made up of fully inexperienced members, therein will be the ultimate risk and error just waiting to happen at which point there is no easy return even with agile training courses. This is where the self-fulfilling prophecy will come into place whereby naysayers will state that agile doesn’t work in the form of the much dreaded “we told you so.” Continuous improvement has a lot to do with accepting change. When sprints are completed and done properly over time and with additional coaching and mentoring, it becomes much more effective and seamlessly risk-free so that changes become more acceptable.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

How to Recognize Team Synergy in Agile Teams

Posted on by

Ok, so you’re about to start your project and you look toward your resourcing department to get new team members to join the group. You realize quickly, that you want to be sure you can foresee whether or not your colleagues will allow for creating something great and interesting. As you proceed with introductions and discussions, you start to wonder how soon your agile team will reach its fullest potential regarding synergy and the related benefits of reaching that high point.

Team Synergy is NOT instantaneous

recognize-team-synergy-agile-teamsWe must consider that everyone can learn to get along and get the project from start to finish with a deliverable that all stakeholders expected, like a well oiled agile supply chain. Office politics aside, there will be those that have their own hidden agendas, clique mentality and those who will want to do things their “own way.” This of course means they are not team players, but I’m speaking to those who like what they’re doing and prefer to do things as a team. Fundamentally I’m referring those who are professional-minded.

What does this mean for an agile team even with a good set of skills and capacity to deliver? Stages that all teams must undergo over time, regardless of each member’s level of maturity or project methodology you use, it will happen in the same order as the following:

1. Forming: This is the initial stage, and it’s the easy stage. It simply represents the team members getting together, being formally introduced, and everyone getting to know one another.

2. Storming: This next stage is where everyone starts to flex and see what their colleagues are capable of, but also where boundaries are set, whether implicit or explicit. It’s where everyone identifies with their strengths and makes sure everyone knows what their area of expertise is. This evidently, is the stage where most conflict will occur, and as you might guess, is where everyone’s level of maturity will show up. So there will be resistance, and possibly group dynamics that will bend and stretch. A good recommendation at this stage is to get some good agile consulting, agile training courses, or participate in agile games sessions.

3. Norming: This is the stage where the “dust settles from the storm.” Everyone recognizes their differences, and moves to agreement whether pleasant or not, but they work to understand and trust each other’s area of expertise, despite disagreements in certain areas, they take on their roles within the group.

4. Performing: This is typically the final stage, and it’s where the team dynamics and synergy are at their optimal level. In comparison to all stages before it, this would be the fun stage, and it’s typically where you want to keep the agile team intact, motivated, and contributing. Soon after this stage, we would typically adjourn as the project ends. For the best interest of your customers, you likely would want to keep that team intact from one project to another, unless you’re willing to expect a period of disruption. Depending on how many members of the agile team you switch in or out, the impact and time to get back to performing will vary. The potential results gained from a fully functional agile working team reaching this stage is a considerable asset.

Getting There is a Challenge, Staying There is an Even Bigger One

Consider that all these stages are in constant flux, especially when new members are introduced to the team and it’s regardless of whether or not you following waterfall vs agile principles. Another important factor is the size of the team, the larger the team, the more channels of communication there will be and that increased complexity will extend the duration of those stages. Learning to identify each stage as an agile team progresses will help everyone to understand what types of agile solutions and outcomes to expect.

Another point we should not ignore, is the impression that we are in a later stage, when everyone has not entirely transitioned. That is to say, even if the team appears to be “performing” (something I like to call “pseudo-performing”), they may not have actually gotten past “norming,” possibly from the effects of a few bad apples, or members that just can’t agree to anything.

On a final note, these stages cannot be forced on a fixed or expected timeline regardless of whether or not you are considering waterfall vs agile, but they can be facilitated by an agile business coach, an essential part of an agile team. It wouldn’t necessarily be a formal note to the team saying “hey everyone, we’re in the ‘norming’ stage so let’s move on to the next stage.” Rather it would be along the lines of a statement such as “I can see our tasks are progressing well and there’s no major disruptions, everyone is in constructive agreement, we reached the ‘performing’ stage.”

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]