Tag Archives: agile

FWD50 2017: Fail faster and get $hit done in digital government

Ask me what I learned at FWD50 and I’ll tell you this: All the cool kids are embracing digital government. And it’s okay that everyone isn’t doing it the same way—as long as the desired outcomes are kept in view. The real debate is whether or not government can innovate, take the right risks, and fail faster to learn how to achieve long-term success.

Those in the private sector and the venture-capital-funded startup community would tell you that the government is designed to resist innovation and change. Those in government would tell you they’re making progress because they’ve put stakes in the ground. In our FWD50 coverage, we talked up going agile and shaking up the CIO role, but the real fun of digital government comes in when leaps are taken—even if they end in failure. Take a leaf out of government’s book: In order to innovate at scale, you need to embrace a culture of failure and risk. Ontario is a leading example.

Follow the leader: Digital government in Ontario

When it comes to digital government, Ontario’s chief digital officer told FWD50 attendees that most levels of government are speaking from the same playbook—they’re just putting their own spin on it. Hillary Hartley outlined Ontario’s path to digital government with 10 key priorities, including focusing on users and businesses, creating a high-quality user experience, and recruiting talent that can help increase digital literacy and capacity across the public service.

But it’s more than just putting a new coat of paint on existing services and web properties. It goes deeper than that. Why aren’t things working in government, and why aren’t some services being used as much as they should be? Does the service have stumbling blocks that get in the way of usability? Or are citizens simply unaware that the service even exists? When it comes down to it, analytics comes in handy to make small changes that have large impact.

It’s also critical is meeting with stakeholders and policymakers as the province takes iterative sprints. Ontario’s Digital Services Standard puts stakes in the ground it can always come back to, highlighting what it needs to do to stay on the right path. But it’s not stopping there—Ontario’s looking at other innovation hubs to understand what Hartley calls their “methods and madness.” It has a lab at Waterloo’s Communitech, dubbed the “empathy lounge,” that’s dedicated to user experience design for the government’s digital services. But are mandates, an agile approach, and empathy lounges enough for government to truly innovate towards digital transformation?

Don’t overuse “innovation”

If you downed a drink every time someone mentioned innovation at FWD50, you’d be dead. But it was people from the public sector, like Hartley, who pointed out that “innovation” was an overused buzzword.

It’s no surprise that one of the sessions was an on-stage debate asking whether or not government can actually innovate. Private sector speakers called out Quebec’s licensing bureau going digital: Its hours of availability were still nine-to-five per labour union negotiations meant to safeguard full-time jobs. Meanwhile, government employees still aren’t getting properly paid thanks to the troubled Phoenix payroll project, which loomed like a dark cloud over nearly every FWD50 discussion about successful digital government.

So, private sector employees aren’t the government’s biggest fans. On the other hand, its advocates praise the government’s digital savviness, arguing that it innovates every day by doing small things. While the private sector is still searching for unicorns and trying to do things that the government could never do because of its constraints, the government is the “rhino”—it might not be pretty to look at, but it gets $hit done. Take the internet, NASA’s space launches, and safe drug injection sites in Vancouver.

The private sector can acknowledge these bright spots, but tends to see government in only two ways: as lawmakers and as a bureaucracy. Billions have been spent on developing portable electronic health records—but have you seen any of it? It’s safe to say that the government does experiment, we’re just not seeing the delivery.

At the end of the day, is it really about government versus the private sector, or is it about the ability to innovate at scale? Large businesses struggle to change course, too. Startups burn through venture capital money only to fail anyway. The government doesn’t have the budget for 10 different trials of e-health—so it has to make a big bet that might fail.

Given government’s commitment to be more agile as part of its digital transformation efforts, it’s becoming leaner, taking smaller bets and more risks. But does it have a culture that tolerates failure so it can learn to innovate better?

Get used to the word “failure”

The problem isn’t that government fails, it’s that it doesn’t talk about its failures in constructive ways. We’re not comfortable—well, most of us aren’t—saying things suck. But even the federal government CIO Alex Benay knows it’s time to get comfortable saying the word “failure,” or even admitting that a project is crap. In fact, he had a whole session about failure and culture on the last day of FWD50.

It’s not enough to just develop policies around the use of technology and how it’s deployed. Another session (quite painfully) illustrated how problems affecting citizens need to be solved. Canadian citizens, immigrants, and vulnerable people often bear the brunt of IT systems that don’t work, leading to unbearably long waits for citizenship or barriers to necessary medical care that keep them from being productive contributors to society.

For digital government to succeed, IT to innovate, and citizens to be taken care of, you need to create resiliency around failure so staff members aren’t afraid to come back into the office when things to go wrong. Benay’s take on it is if your leaders aren’t creating that space, find another job. Go to a leader that creates that space. We all have to be able to get back on the horse, because doing nothing is much worse.

So let’s wrap it up with this: The government needs to get better at breaking work down so it can learn from mistakes and start to do the cool stuff that actually works. Learning to fail is essential in going digital. Like Benay said, policy may be considered sexy, but doing $hit is more fun.

Featured image courtesy of Eva Blue.

FWD50 2017: Government’s going agile, and so can you

If you’ve ever quickly dismissed the idea of working for the feds because it seemed way too slow and bureaucratic, think again. At the FWD50 conference in Ottawa, many of the attendees are public sector employees tasked with guiding digital transformation projects through a more agile government. It’s a meeting of great minds working together to bring tech into brighter focus to better Canadian government, and there was no shortage of tech possibilities brought to the table.

Day one of this conversation on digital transformation focused on workshops all about moving to a digital government, including sessions on becoming agile, data science in government, moving from technologist to digital enabler, and beyond. At FWD50, these conversations take on a government scale but echo strongly for ITDMs throughout the country.

The Canadian government has seen so many failed projects that it’s been forced to change its game—under top-down guidance from the Senate and Treasury Board. But it all goes beyond just software and information technology. To transform, everyone needs to participate. Just like government employees, it’s time to get out of the trenches of technology delivery in your workplace and help your business do better. Here are some key insights for ITDMs from the collaborative discussions that took place at FWD50 day one:

1. Know your customer

When you think of digital transformation and the adoption of agile methodologies, the government probably isn’t the first thing that comes to mind. In reality, the two are fuelled in part by the government’s core mandate to create value and a better life for Canadians. The problem is that the current state of affairs is no longer sustainable.

The Canadian government supports the IT requirements of various departments through its Shared Services model, but remembering who the actual client is can get a little messy. Is it the department, or the tax-paying public? Agile is all about focus, and a government moving toward digital transformation needs leadership that remembers the who and the why.

2. Admit that you don’t know everything

The current state of government projects has everyone making assumptions. And you know what happens when you assume, right?

Today, the practice is to create reams and reams of documents up front, collecting information that outlines what’s known, what’s unknown but can be known, and an acknowledgement of the things that “we don’t know that we don’t know.” Well, this is where a vendor comes in, and why the government runs into challenges. It takes two to three years to publish these assumptive documents—heck, you’re writing books—that go to tender and uncover requirements and architectures. You’ve spent a pile of money already, and you’re still just making assumptions about what’ll happen during implementation.

Embrace the chaos of not knowing everything. The honesty will set your team up for greater success, unhindered by delusions of absolute control. Speaking of which…

3. Accept that you’re no longer in control

So, the RFP goes out and the contract is awarded to a vendor. RFPs are indicative, and the awarded contract is full of numbers. That’s when we run into what we didn’t know we didn’t know.

Any complex project—IT or otherwise—isn’t getting validated until after the contract is awarded to the vendor. More often than not, we realize what we really want is a capability that didn’t exactly occur to us during the three years we were writing assumptive documentation. Now, we’re no longer in a position to negotiate. At this point, the vendor is managing your world—and you’re just living in it.

The current process is designed to reduce risk, but everyone’s secretly sweating it out, because not having validation is the riskiest approach of all. And that’s the problem the government is trying to solve with agile.

4. Know that culture shock is real

Ironically, agile runs contrary to the massive undertaking of digital transformation. Agile’s about small change, and the opportunity to evolve—not rapidly transform—into a more agile organization. It gives you adaptability.

Agile isn’t something you can buy. It’s a culture shift and a mindset. It’s simple, but it’s not easy to implement in just any large organization. The culture change has to happen before you can have better collaboration, and that can take a long time.

But what starts sooner is implementation. So instead of taking a long journey into a vendor contract, you should start to validate things as soon as possible. This kind of culture shift is more difficult.

5. What red tape?

Without a doubt, there are still constraints in agile government. It still needs to be auditable—and building that feature in isn’t a trivial thing to do. The shift is to stop throwing that up as a barrier; agile sees it as a problem to be solved.

Another thing to understand about agile is that it isn’t prescriptive. It’s not about replacing one way of doing things with another, singular way of doing things. That actually defeats the purpose. If you roll out a prescriptive process, it won’t lead to outcomes you want. What agile is about is making sure people have the tools they need and letting them do the work they know how to do while keeping the outcome in mind.

6. It’s OK to say “oops”

The current mindset is to go big—but don’t make mistakes. Iteration is core to agile, and that’s where you find the problems. It’s another big culture shift: To be transparent, your coworkers will need to speak up if they see that something has gone wrong so everyone can course-correct.

When a project’s done in little pieces, it puts the validation up front and better mitigates risk. It lets you make a mistake, realize it quickly, and talk about how to get back on track. In a complex environment, it doesn’t make sense to try to predict everything. There’s a lot to be said for positivity, but not when it gets in the way of reality.

Agile is disciplined, but it’s a structure that acknowledges that things are going to change. Are you ready to dabble in the art of the possible? Follow along with Tektonika as we dive into days two and three of FWD50 next week and uncover what ITDMs can learn from the government’s focus on digital transformation.

Featured image courtesy of Eva Blue.

Lean vs. agile—it really matters which comes first

There are a lot of buzzwords thrown around in the business world, but two of the most common terms—”lean manufacturing” and “agile”—are also the most misunderstood. MindTools describes the meanings behind these two words as core to how administrators view their teams. Right now, everybody seems like they want to construct a lean business in pursuit of becoming as agile as possible. Unfortunately, in development, the lean vs. agile relationship really works the other way around.

Getting agile, growing lean

In short, to be “lean” is to be without extraneous parts—without inefficiency or waste. It’s too often assumed the way to become agile is to simply strip away the outer layers of a business, from its expenses to its roster of employees. In reality, the cuts that can transform a bloated business into a lean one need to be holistic, affecting budgeting and organizational processes from the bottom to the top. With that more difficult and worthwhile goal in mind, however, a new problem presents itself: How can you know what to throw away and what to keep?

That’s where agility comes in. Agility is a property of companies that prioritize meaningful personal interactions between employees and customers, which focus on adaptive, reactive decision-making processes that can quickly find even nonlinear solutions to complex problems. The Agile Manifesto, first released more than 15 years ago by a host of respected figures in software development, lays out the ideas behind this paradigm.

As mentioned, many first assume that a business can achieve the goal of becoming agile by going through the austerity process of becoming lean; if we cut away the layers, then we’ll be left with only the most efficient parts remaining. However, without an accurate means of identifying which parts need to go, the quest to become a leaner company can amount to little more than self-amputation of useful limbs.

Who wins out?

In reality, the most effective companies first focus on the type of agile development philosophies that can help them succeed. In this paradigm, the best, most agile strategies will naturally highlight the least agile parts of a company. So, if you implement the agile principle that face-to-face conversation is the most effective way to convey information within a development team, it should become immediately apparent which aspects of your company contribute to that goal and which don’t. By narrowing the definition of the organization’s goals, you can make achieving them far simpler.

Crucially, this does not necessarily mean you’re just constructing a list of people and processes to cut—lean does not equal small and without unnecessary parts. If resources are used in unnecessary, non-agile ways, those resources might be more effective when reinvested elsewhere rather than saved for short-term gains to the bottom line.

Another one of the core principles of agile development is that technical excellence is a key to building the most effective companies—that’s always a good maxim to consider. Also, bear in mind that agile companies can quickly react to changing circumstances, which means they don’t tend to maintain only a bare minimum of resources on hand. While a company might prove leaner with a smaller QA department, it’s not very agile to create flawed development processes that will just end up costing you time and money in the future.

There’s simply no lean vs. agile debate—they’re extensions of the same overall approach to improving your business’s effectiveness. In general, being lean is about eliminating things that don’t have direct value to your company, while agility is all about knowing where that direct value comes from. You can’t achieve one without the other—if you cut without wisdom or add new parts and innovations without restraint, you’ll ultimately miss the benefits of both the lean manufacturing and the agile development paradigms.

In an ever more competitive business world, that’s not a risk many can afford to take.

Tenets of agile—maximizing the work not done

Today’s IT teams are adopting the agile methodology far beyond the realm of software development—think team collaboration methods and a self-organizing culture.

In fact, McKinsey director Paul Willmott believes most organizations can glean lessons from the Agile Manifesto on minimizing complexity and increasing decision velocity. Willmott says that rapid decision making is at the heart of agile techniques, like scrums. “Small cross-functional teams work side by side, checking in daily for quick progress updates and problem solving,” he explains. “Working at this pace means focusing on fewer objectives and putting in place well-defined controls, such as decision rights and risk guidelines.”

Agile just makes sense in a broader IT context. Reflection at regular intervals? Customer-focused processes? Huddles? Sure. These ideas make perfect sense at a higher level. But buried deep in the Agile Manifesto is the tenth principle, which is often a source of confusion. It states, “Simplicity—the art of maximizing the amount of work not done—is essential.”

Though the manifesto arguably evokes poetic form (it’s even in stanzas rather than a numbered list), this tenet is the only component of agile that delves into “art.” It’s also pretty confusing at first glance, especially if you’ve been compulsively driven to “get stuff done” your entire life. We took a journey to discover the true meaning of this idea and whether it’s worth your time.

In defence of not getting stuff done

You’re probably familiar with some abysmal case studies on IT project failures. The statistics on project management are decidedly not great: up to 75 percent of IT executives anticipate their projects will fail from the beginning, while Harvard Business Review found that one in six IT projects go over budget by 200 percent and exceed their time line by 70 percent.

Organizations need to control for complexity and do everything they can to keep their projects simple. Simplicity could be the single most effective way to prevent failure. Consider MailChimp, which surpassed iContact in features delivery while having fewer people on the tech team (20–30 employees for the former, 100 for the latter) and being truly agile, according to former iContact employee and agile consultant Robert Galen.

Galen also dives into the story of Unix, which you may know from its product Linux. Their original, simple architecture was elegant and streamlined, offering only what users needed and used while allowing for more complex erecting when required. Small teams with defined goals can make huge impacts on technology.

Attack the 80 percent

Think of Microsoft Excel or your smartphone. Do you use its complete functionality on a consistent basis? If you’re like most of us, the answer is definitely “nope.” Research by Standish Group reveals the average technical project results in an 80–20 percent split. Only 20 percent of features are used often, while the other 80 are used infrequently—or hardly ever.

While this knowledge is critical for IT workers who develop technologies, it’s also an important life lesson. When your IT team works on any number of projects, from security to policy, will 100 percent of your work have a real impact? Chances are, it won’t. Focus on perfecting the 20 percent and eliminating as much of the rest as possible—especially if it doesn’t provide any real value to your team or your customers.

Suman Bhowmick of the Scrum Alliance recommends a simple, three-part questionnaire that’s invaluable for weed-whacking useless work in a ton of IT settings. Before you add an item to your to-do list, ask the following:

  • Will it deliver valuable outcomes?
  • Does it cost more resources (time or money) than the value it provides?
  • Does it duplicate work we’ve already done?

Team collaboration is an art

The ability to consider time, budget, technical restraints, and even emotions while remaining agile is far more than a science. Learning to say “no” requires a constant reevaluation of competing priorities. What worked for your IT team last year could be the wrong decision today. Agile enthusiast Aaron Krumholtz stated, “Maybe it is insanity, but I think we do need to ask the same question over and over, and expect a different answer.”

From the time we enter the workforce, we’re trained to use team collaboration sessions to create massive to-do lists, and then retreat to our work stations to plow through our tasks at a breakneck speed. While this ethic is certainly admirable, the tenth principle of the Agile Manifesto begs to differ on its effectiveness. By working with others to assess whether projects, features, and tasks actually have value, you can maximize your team’s impact in very real ways.

Creating a fast, flexible team built for IT agility

Have you ever been confronted by an impatient CEO who wants the business to be more nimble and able to capitalize on emerging opportunities to outpace the competition? This might be an all-too-familiar scenario. With companies big and small becoming increasingly dependent on tech in all areas of their operations, it’s critical for IT to cultivate and practice flexibility in response to rapidly changing business needs. Fortunately, thanks to the IT agility that results from using the agile methodology, there are many smart techniques your team can use to tackle this new reality with energy and resilience.

IT agility—and why it matters

Although the agile framework was originally created for software development, it’s now used to deliver value on a broader scale throughout the business. People even talk about agile marketing and agile human resources. So, how can IT agility benefit your team?

If you’ve ever managed a traditional project, like rolling out a new mobility solution, you’ve probably run into every project manager’s nightmare: encountering a new requirement or seemingly unwelcome change just before launch. Traditional project management processes, like the Waterfall model—which requires you to tackle work in separate phases with requirements fully defined upfront—don’t handle these sudden changes well. But since these out-of-the-blue changes are a regularly recurring feature of IT projects, we need a better solution to respond to them.

An agile approach allows you to stay focused on your main goal while flexibly responding to emerging challenges and opportunities that inevitably show up along the way. By adopting iterative, two-to-four week sprints (work cycles), which allow you to break work into bite-sized chunks, you have an opportunity to review where you are at each incremental point in the project before beginning a new piece of work. You can also choose to accommodate any changing requirements that may surface at each point along the way. This is in line with values promoted in the Agile Manifesto, which tout a “ship early, ship often” approach—putting the customer at the centre and promoting constructive collaboration.

While this approach fosters more flexible project management, it can also pose a challenge when it comes to team dynamics. An agile team doesn’t behave like a regular project team and needs special care to work well.

Assembling an agile team

It’s essential to build an IT team that can quickly react to changes and continually improve itself, all while staying on task in a rapidly changing environment. Sound fun? This begins with forming a cross-functional team that eliminates silos. You may even want to include a non-tech colleague when assembling your team, depending on the circumstances, to ensure steady feedback from your customers or main stakeholders.

You also need to make sure each member of the team is dependable, both in terms of submitting work on time and communicating well within the group. Without good communication, a breakdown in the psychological safety that’s so critical to agile team success will quickly ensue, endangering the project’s progress. Your team needs to be stable, self-healing, and resilient when things don’t go according to plan—ideally without an active, guiding hand from leadership. Your team should also view mistakes or challenges as learning opportunities rather than showstopping obstacles.

As an agile IT team leader, you need to prioritize communication even more than you might when leading a traditional project. This means giving clear overall goals for your project and incremental objectives your team will tackle in each sprint. It also means supporting and encouraging frequent, collaborative communication within the team.

Foster a culture of trust and empowerment in your group. This might include inviting team members to participate in the planning process or providing them with specific roles and positions of authority within the project according to their skills. As they become more experienced, your team members will develop and strengthen the critical thinking and problem-solving abilities that will serve your business well, time after time, project after project.

The agile way

Ultimately, IT agility represents a more current, customer-focused approach to IT service delivery. If you and your team have ever been told you need to be more responsive and less stuck on procedure or policy (like pretty much every IT department on the planet, no doubt), you probably want to take a look at the flexibility an agile approach can offer. You don’t have to abandon due diligence or discipline—far from it—but you may just find that you’re able to navigate and adapt to changes more easily as they come. That’s a capability any IT team would love to have in abundance.

5 ways to build an agile team

Creating an agile team can be a delicate art, especially in IT. It’s the challenge every IT decision maker faces: How do you pull together a group of tech professionals with different skill sets—not to mention different mind-sets—and bring out the best in each of them? Sometimes, a little extra attention to the softer or more human side of things can go a long way, although it may not come naturally.

However, millennials are disengaged, according to a recent Gallup poll, and a disengaged team is anything but agile. What’s it going to take to master agility and resilience?

1. Honour psychological safety

Psychological safety is a major success factor for an agile team. If your team members don’t feel safe expressing concerns or doubts (or simply taking risks) because they always feel like they’re one step away from the chopping block, you won’t get their best ideas.

If you create an environment where your team feels free to respectfully disagree with one another (even you) and make mistakes they can learn from, you’re more likely to see innovative and creative thinking within the group. When your team gets a confidence boost from having that sense of security, you have a better chance of retaining your best staff. And a close-knit team will become even better at tackling big projects and solving tough problems in the future.

2. Be transparent and vocal

Long before IT was a thing, poor communication wreaked havoc in the business world and beyond. Millennials in particular need good communication to thrive at the workplace. As an IT leader, you owe it to your team to make their goals crystal clear—otherwise, confusion may creep in, resulting in a dip in morale, or worse, an outcome you hadn’t intended. This is especially true if your IT employees telecommute, because effective communication is even more of a challenge in a remote setting.

Make sure everyone is on the same page by spelling out deliverables, due dates, and accountability for each task. Your agile team members want to understand their roles and responsibilities, but they’re also looking for a sense of where they fit in and how they’ll contribute to the team’s success. Once they know the team’s goals and their role in achieving them, they’ll be far better equipped to make a positive impact.

3. Nurture the right skills

If your business is rapidly changing, you’ve got to deploy the right skills to help it meet the next wave of challenges it faces. I don’t mean just tech skills here—many of the abilities your team members will need to have at the ready are considered soft skills. To start with, they need to be fully aware of their strengths and weaknesses. But awareness alone isn’t enough. Each member needs to be actively working on ways to accentuate their strengths while addressing the areas that need improvement.

Those on your team must also be open to feedback from others in the group, which supports strong communication. Beyond that, adaptability in the form of critical thinking is a must. To take on increasingly complex challenges, your agile team must reflect on what it already excels at—and how it can do even better the next time.

4. Remain steadfast when approaching challenges

As we all know too well in IT, it’s not always smooth sailing when you’re trying to get a project off the ground. But, when handled the right way, challenges can be valuable opportunities for group learning and team bonding. Your staff needs to know that roadblocks happen and that you have faith in them to find a solution.

Think of the IT achievement you’re most proud of. Chances are it involved confronting and resolving some sort of challenge along the way, and you came out the other side stronger and smarter as a result. Support your team in tackling difficulties, and you’ll find your team members even more confident and energized once they’ve cracked the code and found the fix.

5. Create a sense of purpose

No team can truly go above and beyond if it doesn’t have a sense of purpose. What’s the mission of IT at your company? What does success look like to you and your agile team, and how do you want to set yourselves apart within the company? While outlining clear goals on a project or task basis, it’s important to have an overarching sense of purpose—the “why” behind what you do—and communicate that to your team. Once your team becomes invested in your collaborative work, you’ll be surprised at just how much you can accomplish together.

With these focuses, your team will be able to create the agility and resiliency needed take on any project that comes its way, enjoying greater satisfaction and fulfillment in the process. So tell us: How are you leading your agile team to success, and what IT heights do you aim to achieve next?

How a lean IT team can weather the tech funding slowdown

Murmurs up and down the hallways of venture capital companies suggest we’re in a technology funding trough. Despite this setback, though, a lean IT team can still survive and thrive. Since investors are focusing more on tangible value and less on the promise of big returns in the future, tech companies must do more with less. Those constraints will eventually feed through to IT teams in small tech companies. The smart ones will already be focusing on delivering the maximum value with minimal budgets.

A lack of funds

The slowdown in funding is showing up in industry figures. In Q3 2016, KPMG and National Science Foundation-backed analytics firm CB Insights released their quarterly venture capital report, which showed a 14 percent fall in total quarterly funding, representing the lowest quarter of ready cash for startups since Q3 2014. Mega-round funding is dropping as deals shrink, and the number of new ‘unicorns’—companies that break $1 billion in market value—has also slipped.

The slowdown in venture capital must stem at least in part from a slip in the funds available to VCs themselves. The National Venture Capital Association’s 2016 Yearbook found that capital committed to venture firms fell almost 10 percent in 2015 to $28.2 billion. While it’s true that 2015 funding still led the funding available in 2012-13 by several billions, it’s worth noting that the slowdown over the previous year occurred in the second half of the year, shadowing strong concerns about the global economy that continue to grow.

Many startups rely on a lean IT team for innovation, producing products for customers and internal systems that can provide a competitive advantage. They may call on those teams to become more efficient, excelling in their technology development even as budgets fall.

Learn to be lean

Development teams can concentrate on two qualities to meet this challenge: leanness, and agility. These two buzzwords are sometimes used interchangeably in the tech community, but they’re distinct concepts, argues Abby Fichtner, hacker in residence for the Harvard Innovation Lab, and former startup evangelist at Microsoft.

Informed by lean manufacturing principles, Fichtner defines leanness as eliminating anything that isn’t adding value and only working on what is necessary at any the time. Leanness also means deferring commitments in a project until the last possible moment, on the basis that conditions may change. After all, why build something now if it may not be needed in the future?

These lean principles also inform Eric Ries’ Lean Startup model, which encourages developers to build the minimum viable product now so that they can learn what the customer cares about, and then use that feedback to inform the next stage of development.

Aggressively agile

Agile development relies on lean thinking but applies it in the form of methodologies that focus on customer satisfaction and frequent software delivery. The Agile Manifesto, which forms the basis for the agile movement, includes 12 principles. These encourage development teams to interact with business users frequently and deliver new releases of software in short ‘sprints’ that quickly reflect user feedback. The idea behind agile development is to avoid potboiler projects that simmer for so long without user input they sour and become irrelevant to the business.

Although agile development relies on lean thinking, the two concepts also share some explicit principles. Each of them empower individual developers and their business counterparts to get the job done. They encourage teams to slim down projects and reward developers for concentrating on only the necessary work rather than irrelevant bells and whistles.

An IT team that thinks lean can act agile. It can deliver a more effective product by understanding the essence of what that product is meant to do, and focusing purely on those things. It does this by learning from its users and feeding that knowledge back into its innovation process. Is your IT team ready to be a lean, mean, agile machine?