@Scale the AgileCraft Blog

Don’t get Stuck in the 80s (Hair Bands Excluded)

Posted by Steve Elliott on Jun 15, 2016 9:52:51 AM

 

 

 

The 80s were a big deal to my generation.  The 80s shaped my earliest memories.  I cherish the dawn of the personal computer, video games, hair bands, rap, break dancing and so much more from back in the day.  In terms of how to drive culture I have held on to literally nothing that was embraced in the 80s.  For culture I look to the last 15 years of innovation for inspiration.    

In terms of management culture what has changed since the 80s?  Just about everything.  In addition to the changes with the attitude of a servant leader, middle management’s role in development, self-organizing and rewarding teams versus individuals … a culture of continuous measurement with rapid feedback loops to adjust the plan for maximum results also has a significant impact on culture.  This is especially true when turned inward to the employees of an organization.

Did you know that John Deere measures employee engagement and morale every two weeks?[1] A company that achieved earnings of $1.94 billion in 2015 reaches back into their immense employee base every two weeks. That’s 26 times per year they are successfully conducting employee engagement surveys. So you may be wondering why such an intense focus on the employees every 2 weeks?

The reason …happy employees make happy customers. Employee measurement is the easy part, but that raises the next question: how do you create happy employees? The answer in my view is to implement an Agile methodology and mindset.

So, how does that translate into happy employees and a great culture? Imagine if you were working on an assembly line and you never got to see what the final product was. Day after day you did your part and completed your part of the task. Six, nine or even twelve months later, you were still working on the same product.  You didn’t know what others were doing and you didn’t think the broader company was aware of your efforts. Yes, you may have been rewarded for your efforts along the way, but don’t you want to see the final product? The fruits of your labor? Well that’s were Agile changes the game.

In Agile, “The highest priority is to satisfy the customer”.[2]  Agile is worth the price of admission because it enables companies to drive better results. Agile allows for increased flexibility, which enables teams to better react and meet their customer’s needs.  To leverage a famously overused cliché from Walter Gretzky (Wayne’s Dad), companies want to “Skate to where the puck is going, not where it has been.”

Agile generates increased visibility of IT led activities within an enterprise. It creates an environment that promotes an inclusive culture through collaboration.  This results in a culture that not only requests, but welcomes inputs into projects from all business units within an enterprise.  Agile done right creates a culture that allows for experimenting and more importantly, collaboration.

Unlike other methodologies that rely on a project plan with features and goals set at the beginning of a project, Agile follows an incremental, iterative path. Agile allows for changing requirements over time. Based upon early and often feedback, the team can determine if they are headed in the wrong direction and quickly pivot. This results in eliminating the development of features that customers no longer need or want, while also eliminating the frustration within the development team.

By living and breathing in an Agile World, enterprises are more productive, able to respond and react to customer’s requests, increase internal visibility, and improve employee engagement and satisfaction. Ultimately, it results in happy employees.

So whether you refer to it as a mindset or a methodology, we all understand moving to an Agile environment isn’t easy and it isn’t a magic bullet. When your enterprise makes the decision to embrace Agile, the benefits reach farther than just the technology; it reaches to the people and ultimately the culture as well.

So put on a good hair band, grab a big white board and then design your internal feedback loops for a better culture.  Just remember to iterate on your internal process frequently and be relentlessly repetitive with messaging to the entire organization the benefits of a lean / Agile culture.  The result is a highly transparent culture that is always on the lookout for ways to better engage the team and by extension the customer.

At AgileCraft, we deliver the most comprehensive software solution available for scaling agile to the enterprise. AgileCraft transforms the way organizations enable and manage agile productivity across their enterprise, portfolios, programs, and teams by aligning business strategy with technical execution. To find out more visit us at www.agilecraft.com or follow us on twitter @theagilecraft or download our latest whitepaper An Insider's Perspective: Bank of America

 

[1] https://hbr.org/2016/05/why-john-deere-measures-employee-morale-every-two-weeks

[2] https://www.Agilealliance.org/Agile101/12-principles-behind-the-Agile-manifesto/

 

 

 

Read More

Topics: Bi-Modal, SAFe 4.0, Enterprise Scaled Agile, Culture

Agile vs. Waterfall – It’s Debate Season Again

Posted by Steve Elliott on May 18, 2016 8:36:00 AM

Agile vs. Waterfall – It’s Debate Season Again

My view is we can declare the debate between Agile vs. Waterfall over, but before we do, let me attempt to make the case. Late last year, Gartner released a report highlighting the need for CIOs to embrace agile development along with a recommendation that IT leaders and executives adopt this methodology as quickly as possible.[i]  With many CIOs and IT leadership under intense pressure to support fast-evolving strategic transformations, companies are finding traditional project and software development methodologies unsuitable, according to Gartner. Enterprises are turning to Agile development to speed up projects and illustrate their value and companies that delay the decision are paying a big price in the market.

Technology leaders instinctively know that companies in the modern technology-driven era that are unable to drive a process that is built for rapid evolution will struggle to compete. So the why is well established but the how is still a little muddy for some.   The same driver that has been there for the last 20 years is still at play. The difference is the processes and tools to do agile at scale are now becoming main stream.

Let’s look at the two concepts one last time and discuss both approaches starting with the waterfall method.

Waterfall - The “Traditional” Methodology

Often called the traditional or classic approach – this method is linear and sequential. Waterfall is one in which each phase of a product’s life cycle takes place as part of a flow or a sequence of events. One step leads to another, hence the name Waterfall. Progress on one step needs to be completed before the next step or phase can begin. Once the concept is created it moves to design, then implementation and then further down the line until the product development cycle is completed.

In this method, all the planning is completed up front. All the requirements gathering, design work and more has to be completed before any development and coding begins. Once the project moves on from one stage to the other, there is no turning back.

Companies that followed the Waterfall methodology achieved these perceived benefits:

  1. Requires less coordination due to a stage-gated sequential processes
  2. Phase steps are clear since they are modeled and processed one at a time
  3. Cost of the project can be estimated after the requirements have been defined
  4. Better focus on documentation of designs and requirements
  5. Design phase is more methodical and structured before any software is written

Agile – A “Movement”, not just a Methodology

Agile evolved out of a variety of software philosophies to demonstrate alternatives to Waterfall. In early 2001, a group of software development practitioners discussed their shared ideas and various approaches to software development. This culminated in the introduction of Manifesto for Agile Software Development and the corresponding twelve principles. [ii]

Agile software development methodology is an approach that follows an incremental, iterative path. Unlike the Waterfall methodology, where extensive planning and design occurs up front, Agile methodology allows for changing requirements over time. A cross-functional team made up of designers, developers, testers and more focus on development of the product over a fixed period of time. This defined period of time is established by the team and usually lasts 2 – 4 weeks.

At the end of each iteration, the goal is to present a product to the business owners. The software is delivered incrementally over time instead of delivering one final product at the end. Each phase is a key part of a continuous process vs. a fixed step by step approach. With the Agile methodology, the focus is on consistent communication and short feedback loops. So, if a team is heading in the wrong direction, the feedback they receive will let them know right away vs. waiting until a lengthy development cycle is completed.

Agile provides the following perceived benefits:

  1. Faster Feedback Cycles
  2. Identifies problems early
  3. Higher potential for customer satisfaction
  4. Time to market is dramatically improved
  5. Better visibility / accountability
  6. Dedicated teams drive better productivity over time
  7. Flexible Prioritization focused on value delivery

 

 Which approach is better?

This question seems to never go away but the software world is finally turning the corner on the debate. Two truisms: Software Eating the World = TRUE and Agile is Eating Software = TRUE. There are cases for a slower and more stage gated process with some projects but for the vast majority agile is the future.

Blending the two worlds is important during the long transformation journey but the debate on the merits is clear. With the continuing need for enterprises to retain a competitive advantage in their market place, Agile is an established methodology allowing companies to drive better results (plain and simple).

Agile allows for increased flexibility, which enables teams to better react and meet their customer’s needs. Agile creates the ability for companies to capture maximum value for the dollar and avoid unnecessary overhead / budgetary spending.  

In the end, it comes down to enterprise business agility. What you call your software process / method is not the point. The point is your process had better be flexible enough to drive innovation and keep up with your market / your competitors or you may end up the Kodak, Circuit City or Blockbuster of the software world.

What’s next? Check back for part 2 of our series “We’ve decided to go agile, now what? Key steps to readiness”

 

[i] Gartner clients report "Ten Things the CIO Needs to Know About Agile Development."

[ii] Principles behind the Agile Manifesto http://www.agilemanifesto.org/principles.html

Read More

Topics: Bi-Modal, SAFe 4.0, Strategic Planning, Enterprise Scaled Agile

Using Agile Based Strategic Planning Across Your Enterprise

Posted by Steve Elliott on Mar 11, 2016 5:00:00 PM

 

What does it mean to have an “Agile” strategic planning process?

Read More

Topics: Bi-Modal, SAFe 4.0, Strategic Planning, Enterprise Scaled Agile

What Agile Design Teams Need to Know About SAFe® 4.0

Posted by Kyle Byrd on Feb 16, 2016 2:05:15 PM

Just a few weeks ago, Scaled Agile Framework launched SAFe 4.0 with some great improvements across the board implementing a whole new level of value streams and a tighter connection to the enterprise. You can read more about these changes in our posts on Why I love SAFe® 4.0 and Why I Love SAFe® 4.0 Part II.

So what’s in it for design? 

SAFe integrates pieces of both Lean and Agile UX methodologies eliminating Big-Up-Front-Design (BUFD) and transitioning the design teams towards iterative design and research processes.

Read More

Topics: SAFe 4.0

Why I love SAFe 4.0 Part II – Scaling with AgileCraft

Posted by Peter Jessen on Jan 25, 2016 3:55:36 PM

As I shared in Part I of this post, “Why I love SAFe V4.0,” I’ve been involved in software development since 1978. During this time, I’ve worked for or consulted to organizations spanning in size from 50-75 people to multi-national firms, using a range of methodologies from ad hoc through waterfall and on to iterative and agile.

Read More

Topics: SAFe 4.0

Why I love SAFe® 4.0

Posted by Peter Jessen on Jan 22, 2016 11:38:33 AM

I coded, or at least tried to code, my first program in 1978 in junior high school on a VAX mini using punch cards. That was followed by my first personal computer – an Atari 800 with a 14.4k modem and a cassette player for storage. I’ve been involved in software development on a small and big scale ever since.

Read More

Topics: SAFe 4.0

Are “Special Projects” Siphoning Off Your Best Agile Developers?

Posted by Steve Elliott on Dec 15, 2015 7:40:25 AM

Are 100% of your developers fully allocated to a single agile team? Do you ever have dips in capacity where your best engineers are “allocated” to a special project, a waterfall team or are used as specialists across teams?

Read More

Topics: capacity planning

Introducing AgileCraft 9.0

Posted by Scott Blacker on Dec 8, 2015 10:45:07 AM

At AgileCraft, our point of view is that organizations should endeavor to become agile at all levels from the engineer up to the executive. However, this isn’t always practical as organizational, cultural, and structural aspects of an enterprise usually mean that transitioning to agile is an evolution, not a revolution. During this transition process, organizations need a way to link their traditional processes to newer, agile approaches.

Read More

Topics: Product Announcement

Scaling Agile at a Federal Agency: 3 Core Challenges

Posted by Steve Elliott on Nov 12, 2015 11:25:09 AM

Federal agencies face a number of core challenges when scaling agile software development. The process begins at the team level, wherein groups of five or ten developers define, build, and test their software over a period of a couple of weeks. From there it moves on to the program level, which delivers sections of a particular Value Stream in program increments; and finally to the portfolio level, wherein completed programs are aligned with an enterprise’s business strategy. And at all of these levels, there are challenges to be addressed.

Read More

Help: My Teams Are Agile But My Execs Are Waterfall! (Part 2)

Posted by Steve Elliott on Nov 5, 2015 5:00:00 AM

In our last post we framed an approach that PMOs and Program Managers should take when caught in between waterfall planning and agile execution. Tactical questions you may have include:

Read More

Topics: Bi-Modal