Leadership Archives - Page 7 of 8

Blog

The Tug-of-War Between Releasing Early And Completing The Project

By: David Hawks | Dec 11, 2017 | Article, Leadership

Spoiler Alert: Your Company Could Be Losing Millions

For technology companies, the idea to “release early and release often” is not new and the ability to ship product or product increments in a predictable and accelerated manner is core to Agile. Yet, companies shy away from doing so for two reasons: they can’t or they won’t.

Necessary Feature Or Gold Plating

Longer projects means more opportunity for scope creep, and identifying when a project is complete is actually harder than one would think. When Geneca surveyed almost 600 IT and business executives, the organization found that 77% say there is lack of agreement on when a project is done, a prime symptom of fuzzy requirements and/or lack of business objectives.

The trick for stakeholders and managers is understanding whether that extra feature will actually add value to customers or if it’s just an example of gold plating. Is this extra feature worthy of delaying the release–is it something the customer wants or will it just be one of the 64% of features that are rarely or never used per Standish report?

Even worse, forget having a bad quarter. According to white paper Delivering Large-Scale IT Projects On Time, On Budget, and On Value by McKinsey & Company, the failure of large IT projects, costing $15M+, can actually threaten the life of a company. And some of the biggest contributors to large IT project failures include shifting requirements and lack of business focus.

Accelerated Release Is The Opposite Of Risky Business

There’s this thing we talk about called the “Risk Iceberg.” The risk iceberg is a way to visualize the unseen troublespots inherently caused when product development is worked in phases stacked one right after another: plan, build, test, release. With the traditional method (or Waterfall) a team could use 80 percent of the allotted time and resources by the time they discover a defect. Worse yet, the product could get in the hands of users only to discover they built the wrong product.

Agile breaks up a big project into smaller prioritized chunks of work, known as product increments. These bits are separately planned, built, tested, and deployed, in other words, 100% complete, before the team moves onto the next piece of work. A collection of chunks can become PSPIs, Potentially Shippable Product Increments, that can be tested by actual users. The cycle of build, deploy, and learn means a couple of things:

Teams and stakeholders know exactly how much work is left (no major schedule surprises)
Teams and stakeholders know how users are reacting to the product (no major market surprises)

Accelerated Release, Accelerated ROI

The accelerated release of products means teams can learn from users but it can also mean organizations will start to recoup some of the original investment or even make a profit ahead of schedule. Consider scenario A and scenario B:

Organization A is investing 100K a month for the next 12 months with a 3x annualized return. At the end of the project, the organization has spent $1,000,000. Since organization A is using waterfall, the product deploys at month 13. Assuming the original requirements are correct and the product is accepted, the organization breaks even at 16 months.

Organization B is also investing 100K a month for the next 12 months on a product with a 3x annualized return. However, organization B is using Agile.

At month two, organization B begins to deliver a percentage of product value. Value is delivered incrementally over the next 10 months. The product is complete at month 12.

Organization B becomes profitable at month 9, 5 months before organization A.

Releasing early means the ability to get market feedback, which accelerates learning, which creates a better product. Stakeholders and managers can trim the tail and end the project early if it has been determined that it is good enough. It can also mean being ahead of schedule from a profit perspective. It can also mean saving resources for another project if data shows the current one will or will not pan out. All are much better options than a blown scope or a failed product.

Blog

Overview of Agile Scaling Frameworks – Webinar Q&A

By: Agile Velocity | Oct 20, 2017 | Leadership, Video, Webinar

We recently hosted a webinar exploring 6 major Agile scaling frameworks: SAFe®, DAD, LeSS, Nexus™, Scrum at Scale, and Enterprise Scrum. We had a blast, but we were unable to address all the questions asked during the Q&A portion.

You can find the recording below. We also took some time after the webinar to answer the remaining questions (below embedded video). We hope you were able to shed some light on the different scaling practices. If you have further questions, don’t hesitate to reach out. We will also be creating a white paper about scaling, with extensive coverage on SAFe®.

Overview of Agile Scaling Frameworks – Webinar Recording

1.What framework best fits (or is most adopted) by highly-regulated enterprises (such as financial services, healthcare, etc)?

Both SAFe® and DAD have constructs that make working in a regulated environment easier, such as solution intent, a repository for requirements, and traceability maps.

2. How do these frameworks handle the “exceptions”—last minute, high-priority items that do not fit into the regular timeline? How do you short-circuit the process?

All of the frameworks include the concept of a prioritized backlog, and several have backlogs for different levels. When a high-priority item comes in, the Product Owner (or content manager at the appropriate level) orders the request at or near the top of the Product Backlog. At the next Iteration Planning meeting, the new request is likely chosen.

3. Is there a checklist/comparison chart to pick the right and possibly best framework for an organization?

There are several comparison charts available from various sources. One good one is from Box. We certainly advise the use of an Enterprise Agile Coach to help you make the right decision, as it is often not just a single framework—most enterprises need a custom solution.

4. Do you have a list of companies or products that have successfully adopted each of these frameworks?

These lists and case studies are available on the websites for each framework.

5. Do these methodologies apply to other departments in an organization (with many departments e.g finance, marketing, etc.) OR are they meant for the IT Departments of organizations and software companies (whose only product is software)?

Each of these frameworks is generic and work quite nicely in non-IT environments. Over the last 10 years, more and more organizations such as HR, Marketing, Sales, Operation, etc. are using Agile and scaled solutions.

6. I’ve got about 5-7 Agile teams about to be realigned to newly defined product lines, most currently use Scrumban for execution. I’m leaning towards recommending LeSS to leverage the familiarity with ceremonies and cadence. We don’t have a critical need to incorporate business side at this time, which is why SAFe® was lower. Any pitfalls you see with this approach?

No pitfalls at all. LeSS is a great choice for you, especially if you would like to introduce some Lean economics type thinking into your organization. You may also want to take another look at Essential SAFe®. It is a 2-level approach for Agile teams and Agile programs (no business level).

7. Any quick advice on how to tell if an organization is “doing Scrum well”?

The classic evidence of “doing Scrum well” at the team level is each team is delivering business value each iteration, they are using WIP Limits to optimize flow, and they have tangible evidence of improvements over time.

8. Is the assumption for all these scaling models that “all teams will follow Scrum”? Are there any models for scaling that accommodate organizations with Scrum and Kanban teams?

Absolutely. Both SAFe® and DAD accommodate Scrum and Kanban teams quite nicely. Nexus™, LeSS, Enterprise Scrum, and Scrum at Scale are focused only on Scrum.

If you’re specifically looking to start a SAFe^® implementation, we recommend starting with Leading SAFe^® training. You can explore our public and private training options on our Leading SAFe^® training page by clicking here.

Blog

Advancing Agile By Evolving The Manifesto

By: David Hawks | Jun 29, 2017 | Article, Leadership

The Agile Manifesto was created over 15 years ago. Most of the focus in the Agile/Scrum world since then has been to improve product delivery; we have fixated on how we make the development of ideas more effective. We have improved idea development in the following ways:

Increased Visibility – We can see our work, define clear priorities and we can more easily identify bottlenecks and measure productivity.
Team Continuous Improvement – By implementing a rhythm of retrospectives, self-organizing teams have taken ownership of how they can improve their delivery process.
Predictability – By limiting WIP and getting consistent in delivery, businesses can make better decisions. When priorities change, leaders can make informed decisions about the impact of making a change.
Faster Time to Market – By forming feature teams, investing in test automation and continuously integrating, we can optimize to delivering value quicker.

(more…)

Blog

Invest, Don’t Budget

By: David Hawks | Jun 08, 2017 | Agile Transformation, Article, Leadership, Process

Many organizations we work with are very budget-driven. Many organizations do up front funding and budget management. This process feels good, as having a plan provides clarity and accountability. However, this type of process leads to very bad behavior because of a few huge, and often, bad assumptions:

(more…)

Blog

Agile And The Middle Manager Identity Crisis

By: David Hawks | May 02, 2017 | Article, Leadership

Going Agile causes a lot of change within an organization, from a process, strategic, and cultural standpoint. A side effect of the Agile adoption is the confusion regarding roles and responsibilities, particularly for middle managers.

For middle managers, everyone is telling you what not to do, but no one is telling you what to do. You have been told that you can no longer:

Set the priorities for the team
Assign tasks or participate in planning
Estimate work
Attend Retrospectives or tell the team how to improve their processes

The good news is that with Agile, the tactical work is owned by the team. This frees up leadership to be more strategic.

In an Agile environment, here are four areas I see where middle management can make a huge impact:

People Management
Technical Excellence
Organizational Improvement
Business Alignment

(more…)

Blog

WEBINAR – Stop Sabotaging Your Agile Transformation

By: David Hawks | Mar 29, 2017 | Agile Transformation, Leadership, Video, Webinar

An Agile adoption and Agile transformation require a lot of change at all levels of a company. Most importantly, it’s more than a process change, a concept that can cause leaders to stumble as they move their teams forward. For leaders, it’s important to leave some traditional management ideas behind in favor of a more Agile leadership approach. In this webinar, David Hawks breaks down four major obstacles leadership faces during an Agile adoption and transformation:

Driving vs. Supporting
Lack of Support to Improve
Drowning in a Sea of Opportunity
Focus on Output vs. Outcome

Webinar Recording

Webinar Q&A

Besides time and having management show support, what tips do you have to encourage former waterfall employees to access self-empowerment?

Empowerment takes a mindset shift from the entire team. The best advice would be for managers and ScrumMasters to continuously encourage the team to share their ideas and try new things, and hold them accountable for continually practicing these methods.

Another way to do this would be one-on-one conversations where managers can ask questions to find out what the team needs to continue improving.

When you are changing the way leadership prioritizes items and transforms the urgent projects into a backlog for the team to pull from, what practices do you recommend?

When it comes to prioritizing, you never want to approach it with a divide and conquer method. Instead, use techniques that will bring stakeholders together and get them talking to one another about the projects they want to prioritize. This should be a collaborative process.

You can look for tools online to practice this mindset, such as Buy a Feature by Innovation Games. Story mapping is another great tool that can help a team prioritize within context. You can learn more about this technique from Jeff Patton’s book, Story Mapping.

What’s the biggest factor in moving from downward chaos to upward growth?

So this question refers to the pivot point between Chaos & Resistance and Integration & Practice on our Path to Agility®. You can really see that a team is transitioning into the Integration & Practice stage when they become more comfortable with the language of Agile. This typically takes around 3-6 sprints, which are essentially cycles of learning. It’s important for the team to have this period where they can practice the techniques they’ve recently learned and begin to get comfortable with the new system. A key factor of this cycle of learning is the retrospective, where the team can really focus on how to improve their processes.

Have you seen this practice work well in IT infrastructure teams?

Yes, we’ve seen that Agile’s core principles still apply. However, Kanban typically works better than Scrum when it comes to IT infrastructure. Kanban provides a more continuous flow of tasks as opposed to weekly plans. Because IT infrastructure usually deals with more interim driven work rather than work that can be planned out in advance, this framework tends to be a better fit.

What tips do you have for encouraging cross-functional teams in a matrix organization?

This question addresses the biggest factor that keeps organizations from truly getting all the benefits of Agile they are seeking. However, finding a way to address this is difficult because it’s not a one-size-fits-all solution. It really depends on the culture of the organization.

Some companies have fixed this by having feature teams initially report straight to the VP. This empowers the teams and stops them from continuing bad habits that arise from reporting straight to output focused managers. Then, once the managers also get a handle on their new outcome focus, they are placed into the feature teams. This process can help encourage a smoother transition of the company mindset from output to outcome.

Is this directed primarily at software development or an overall business operational culture?

Most Agile adoptions come out of the software world but Agile methodology applies across the board. Often, organizations think the problems are confined to the software department when in reality the entire organization needs to change. From the executives to HR to marketing teams, Agile is effective for all levels and parts of a business.

For organizations where there is a clear strive to meet business commitments and deadlines, how do you help get senior leadership more open-minded to allow a learning environment, particularly if there are offshore teams involved, which has a cost associated with it?

The first question we ask senior leaders is this: “Are you happy with how IT is working?” Not surprisingly, their answer is always no. There is nearly always a disconnect between IT and the rest of the company. Deadlines are handed out like free candy but rarely met. This creates a level of distrust.

Agile provides senior leaders with a solution to this problem but they need to be as involved with the change as IT. Senior leaders can help by allowing time (3-6 sprints) for teams to make mistakes and test out new ideas. The organization can eventually get to a point where they are rebuilding trust by demonstrating a higher level of predictability.

Blog

Do You Know Your Company Objective?

By: Guest Author | Feb 09, 2017 | Article, Leadership

In 2014, Rick Klau gave a seminar on OKRs at Google. He explained how the multi-billion dollar company started using this methodology as their internal grading system since they were a 40 man team. What is more astonishing is that more than a decade later, Google still uses OKRs across the entire organization. Suddenly everyone wanted to jump on the OKRs or Objectives and Key Results bandwagon. Quite a few Silicon Valley companies already use OKRs extensively to manage their goals.

So what sets OKR’s apart from other goal-setting frameworks?

Some of the earlier methods advocated setting organization’s goals for the entire year at one go. It may have been great at one point in time when the work environment was relatively stable. Today everything is changing at a rapid pace. Every other day there are technological advances that could potentially change the entire dynamics of how an organization works. Setting rigid goals for the entire year is not only unwise but also harmful to the organization.

Fundamentals of OKRs:

OKR follows a different train of thought. It recommends setting goals at 3 levels of the organization i.e. Company level (Strategic in nature), Team level (Tactical goals) and at Individual level (operational goals). Team and individual OKRs are typically set for shorter durations, either monthly or quarterly depending on the situation. Whereas company goals are set for longer durations, mostly annual as they can’t be altered every now and then. At every level, there are 3-4 objectives and for every objective, there are 3-5 Key results. This varies across different departments and teams.

Justifying The Hype

Intel and Google have been using OKRs for more than a decade now and have set an example for others to follow. OKRs are now regularly being used by LinkedIn, Zynga, Sears, Samsung, Schneider Electric and many others. Each of these has seen moderate to phenomenal success after the implementation. Some of these have even detailed out how OKRs helped to transform their work culture.

When Kenton Kivestu joined Zynga in 2011, it was being trumped by its biggest competitor, Texas Poker. In his own words, their “position in the mobile poker market was borderline comical.” Having worked with Google prior to Zynga, Kenton was already familiar with OKRs and decided to adopt the framework to turn the tables. He made sure that the entire organization was on board with the concept and began implementing OKRs for everyone. In six months, Zynga beat Texas Poker and became the #1 top grossing iOS game.

Similarly, Jeff Weiner was able to transform LinkedIn to a $20 billion company today. The emphasis on creating stretch goals and achieving them within a particular time made sure everyone had a sense of urgency and a higher focus on completing their tasks. Additionally, Jeff concentrated on conducting weekly meetings to discuss how everyone is faring with their OKRs. This discussion was meant to keep the team focused on their goals and help them as and when required.

Are OKRs compatible with Agile methodology?

Agile methodology has overcome most of the drawbacks faced by teams following traditional methods. Going Agile has helped them deliver value-driven products within the desired team while maintaining quality. Though one thing still missing is the team’s ability to track how the product, despite having all the bells and whistles, will help achieve the company’s objective. Not all products, despite being feature-rich, may appeal to the target market. It is necessary to get this information first and then plan your products accordingly.

OKRs help fix this gap. They can be used to prioritize the top focus areas that have the potential of achieving company objectives. Thus, rather than focus solely on building product features, teams are encouraged to focus on iterations that will enable them to achieve their key results. Organizations use OKR’s (particularly the key results) to gauge if the product enhancements are helping to meet the objective.

The Other Side Of The Coin

There is another side to the coin. There have been a few minor cases where a company has not been able to understand how OKRs work and wasn’t able to implement it correctly. Many companies started using it but couldn’t manage it all levels and thus eventually gave up. One such case is Contactually who (famously) abandoned OKRs because they found planning OKRs was a nightmare. They were at a stage where the company was growing rapidly and needed quicker iterations cycle as opposed to locked-in OKRs.

Not every concept will be universally acceptable. However, OKR’s have earned a reputation for acting as a company’s guard rails for staying on track. When coupled with a methodology for frequent checkpoints like Agile, it can be very powerful tool for meeting goals and ensuring alignment across the organization.

This post is by Yatin Pawar. Yatin is a Product Marketing Manager for UpRaise, a performance management JIRA plugin. You can read more about OKR’s on their blog.

Blog

The Frozen Middle And Agile Transformations

By: David Gardner | Sep 29, 2016 | Agile Transformation, Article, Leadership

I was recently asked what in my experience was the most likely cause of gummed-up Agile transformations. I didn’t hesitate in answering “the frozen middle.”

Top-level management buys into a transformation because they hear faster, better, and more predictable. Teams buy in because it is simply more fun (I’m told “funner” isn’t really a word) and they get to build cool stuff. What about the folks between the teams and executive management? Middle management may be ill-prepared for what is needed from them in the course of a transformation. (more…)

Blog

In agile, “Resource” can be a 4-letter word

By: Agile Velocity | Sep 13, 2016 | Article, Leadership, Team

Sometimes I get emails from recruiters inquiring if we have open positions. The following is an example:

Good afternoon,

I was just wondering if you got any open spots for BA ( Financial ) or Network Admin.

I have these senior resources based out of CA but open to relocating nationwide.

Each time I receive these emails, I have to think about what he’s really saying. “Resources?” Oh…he’s talking about people. Then I get this icky feeling similar to when people hear the word Voldemort.

I grasped early on in my agile journey that “resources” can be a dirty word when used interchangeably with “people” or “person”.

By definition, it is accurate to refer to a person as a resource. According to the Oxford English Dictionary:

Resource (n): A stock or supply of money, materials, staff, and other assets that can be drawn on by a person or organization in order to function effectively.

It’s the connotation that makes its usage provocative and careless.

(more…)

Blog

Path To Agility: Adoption Patterns To Overcome Pitfalls – Keep Austin Agile 2016 [Video]

By: David Hawks | Jul 26, 2016 | Agile Transformation, Article, Leadership, Video

Where are you on the Path to Agility?

In a presentation for Keep Austin Agile 2016, David Hawks explained each phase of the Path to Agility journey including examples of typical challenges encountered along the way. Apologies for the abrupt pause in the middle of the video…a fire drill caused us to evacuate. Thankfully, the drill was just that. Watch the full video or read the transcript below.

(more…)