Tag Archives: agile methodology

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.

How business knowledge transforms IT workers into tech superheroes

If IT knowledge is Dr. Who’s sonic screwdriver, then business knowledge is the TARDIS: an indispensable vehicle with the ability to take you anywhere you need to go. On a daily basis, IT leaders and workers are called on to navigate all challenges, from technical disruptions to productivity threats—but with the combination of both IT and business knowledge, IT pros become hyper-valuable.

Technical consultant Scott Norberg is a believer that business knowledge can benefit project outcomes, regardless of an IT worker’s role in an organization. In Norberg’s experience, “Programmers who know what the software is trying to accomplish will make better decisions and will ask better questions. Programmers who don’t will not, inevitably leading to problems down the road.”

For IT leaders, an overlap of IT and business knowledge results in complete communication—not to mention better products. In other words, learning your business can transform you from important to critical.

IT knowledge broadens to business

The agile methodology has made such an impact in DevOps because it’s uniquely focused on business outcomes. By writing user stories with business-focused criteria, you develop clear success measures for your IT projects. IT pros who understand their business, their industry, and their end-users are able to communicate more effectively, solve problems, and act as a conduit between tech and the rest of the company.

Evidence exists that these cross-functional capabilities can have a long-term, positive impact on your career path. Whether you’re aiming for CTO or CEO, you’ll need both IT knowledge and business knowledge. In a deep-dive study on what differentiates executives from your “average employee,” Russell Reynolds Associates discovered that a key factor is optimism. The executives aren’t afraid to actively go after new opportunities, including cross-functional projects due to a fear of failure.

In The CEO Report, Heidrick & Struggles discovered that those who want to lead need “core” experience, which includes exposure to people skills, general management, finance, and more. Also, according to the study, the CEOs of tomorrow will have no choice but to embrace continuous learning. If you have your sights set on the C-Suite, broad exposure to a variety of business functions—while aggressively acquiring knowledge—can be a crucial resolution.

Developing cross-functional business skills

So how do IT leaders learn the critical aspects of business needed to advance their careers? These three strategies focus on leveraging people, experiences, and not-so-traditional traditional education.

1. Be bold

IT pros should take the optimism factor to heart and develop a bold pursuit of internal networking. Make it clear to your manager that you’re eager for cross-functional projects and opportunities. Make an effort to build relationships with individuals outside your department. Attend the marketing department’s brown-bag luncheon. If you pursue opportunities before you and raise your hand when cross-functional projects are on the table, you can significantly speed your business knowledge acquisition.

2. Don’t wait on your employer

Leadership author Dr. Herminia Ibarra has discovered that “stretch experiences,” or taking on tasks outside your typical responsibilities, can be difficult for employees to find. This is especially the case when an employee’s skills are so valuable that the company can’t afford to have them shift their focus from day-to-day operations. However, 62 percent of MBA grads report that assignments cutting across lines of business, hierarchy levels, and functional specialties had a wildly positive impact on their careers.

For some IT pros, the directive to join cross-functional projects isn’t practical, due to talent shortages or corporate culture. If that’s your life, Ibarra advises strengthening your external network and actively pursuing extracurriculars to broaden your industry exposure. Design thinking could be a great place to start.

3. Invest in MOOCs

Enrolling in a handful of massive open online courses (MOOCs) won’t give you the same knowledge of corporate finance as a CPA, but it’s still worth consideration. Coursera offers a five-class specialization in introductory corporate finance, while you can head to EdX to acquire groundwork in the principles of marketing. You’ll emerge with a richer groundwork and tools for cross-functional communication.

IT professionals who understand their business have the weapon to fight against productivity killers and disruption villains. In day-to-day interactions with your colleagues, you’ll be able to offer relevant solutions. Not only will you gain the potential to really get stuff done, but you’ll position yourself as a business hero.

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?

4 ways the scientific method can transform your IT operations

Your first introduction to the scientific method may have come in elementary school, but it has several hundred years of proven impact that reaches far beyond any textbook—even extending into the world of business. You didn’t learn about the agile methodology in elementary school either, yet it closely mirrors it. In agile, solutions and product features are developed in direct response to business problems. Instead of investing in a full solution, organizations observe and test before making a full investment.

While each has its unique components, agile and the scientific method can both be used to improve IT operations, from company-wide communication to collaboration among teams to product development and launch. Here’s how it works.

1. Observations

The best scientists and IT decision makers are always open to new discoveries via observation. It sounds simple and straightforward, but the process goes beyond simply seeing and analyzing what’s happening in your IT department. Time writes, “Scientists actively engage with their perceptions . . . they organize and analyze what they’ve seen after the observation session is over.” Observation can be even more powerful if it’s based on quantification of events, such as your average rate of software adoption, or the typical deployment time of new applications.

In a contemporary IT department setting, business intelligence (BI) and analytics can be key to the “field notes” necessary for productive observation. Understanding how your key metrics stack up against goals and how they are changing over time can reveal key opportunities for improvement and IT innovation.

2. Hypotheses

These observations lead to drawing a hypothesis, which Live Science defines as a “suggested solution for an unexplained occurrence that does not fit into current accepted scientific theory.” In order for a hypothesis to provide value in a laboratory or IT team setting, it must be testable. “If/then” statements are a common way to format a hypothetical thesis, which can be rejected, modified, or accepted based on the outcome of testing.

Your IT team might hypothesize that a complex UX is correlated with the high rate of errors from your accounting team’s daily processing workflow. You may develop a hypothesis that one-click call logging has improved your sales team’s ability to consistently update contact records. Beyond a hunch, it’s crucial to ensure that your hypotheses are not only testable, but also based on information from your observations.

3. Predictions

Predictions and hypotheses are closely related, but they’re not the same. It’s important to think of predictions as a direct product of your newly formed hypothesis. Based on your hypothesis of how one-click logging has improved end user engagement rates with a tool, you might predict that implementing a similar feature for your accounting team could improve adoption.

Predictions should be made based on data, observations, and hypotheses, without IT team bias. When forming predictions, it’s important to think toward developing ideas that can be tested by groups within your organization or your QA team.

4. Testing

Agile QA processes are closely based on the scientific method. Testing software to “see if it works” is a vague assignment that can set IT teams up for failure. Broad functionality is much vaguer and more difficult to prove than testing single hypotheses, or user stories, as they’re called in agile, to validate single features and workflows.

The concept of focusing tests on a single hypothesis can lend value to your entire IT team. Regardless of whether you’re testing with A/B split testing, analytics results, a QA team, or user focus groups—emphasis on validating or invalidating your hypothesis can lead to better accuracy in test results—and reveal strengths and weaknesses in your observations. Regardless of the outcome, it can strengthen your ability to make sound decisions in the future.

The scientific method has the power to transform your IT department’s strategy, even beyond your in-house software development and testing processes. If your goals include shifting to more agile means of operations, switching to a model of observations, hypotheses, and testing can provide accuracy and nimbleness.