Group items tagged

all the people understand and internalize the concepts and ideals behind the Agile movement

translated into concepts that can be widely applied to the many day-to-day decisions each of them will make

internalize and live three principles: making progress with imperfect information; existing in a high trust, high social capital culture; and shortening cycle times. These ideas need to be infused into the workforce at every opportunity.

it should spread virally. It can start with just one manager, who educates his immediate direct reports on the concepts and then takes the time to reflect and show how each decision is aligned the principles

work-in-progress as a liability rather than an asset.

. Every member of the team should be educated to understand it, and to be capable of demonstrating how their decisions and actions are concomitant with it. The Decision Filter is

The Agile Decision Filter

Delivering quickly can provide immediate value while delay can result in obviated functionality of little value or missing a more lucrative opportunity while completing existing work-in-progress

Are we making progress with imperfect information? Or are we trying to be perfect before we start? Does this decision add or maintain trust in our organization and with our partners? Or does it remove trust and breed fear? Are we treating work-in-progress as it if were a liability? Or are we treating it like an asset?

the team can start to modify their practices one decision at a time and drive towards a goal of business agility

The "transition" to Agile will happen slowly, and supporting the change will require training, coaching and tools – but change will be real and long-lasting.

By changing your culture using the simple principles captured in The Agile Decision Filter, teams will adopt Agile. Give it a little time and magic will happen. They will voluntarily change their behaviors and adopt Agile practices. They will behave in a fashion aligned with the principles and values behind The Agile Manifesto. They will not resist because they had a say in the changes, which are tailored specifically to their environment and their needs.

this approach may seem less prescriptive and straightforward than an "Agile Change Initiative" project plan. And yes, taking on a management-led Agile Transition Initiative looks faster and cheaper,

However, it is all wishful thinking, and the only way to get the payoff is to invest the time and show the courage to lead true Agile change. True Agile change requires you to change the culture. To change the culture, teach all your people how to use the Agile Decision Filter and hold them accountable for every decision they make.

ur last two releases have looked like me-too updates, where we are just barely keeping up with our competitors

We’ve been losing market share

If you can refer to a specific business issue and show the linkage, you are much more likely to get a receptive audience.  Here’s an example.

The CFO, developer and QA manager have different roles in the organization and their needs are different.  If you want to enlist their support, be sure you know who you are talking to and what they value.

Use Focused Messages for Key Individuals or Groups

certain volume of people who are enrolled in the idea of Agile before you’ll see adoption start to accelerate,

People have specific needs in their role and they want to understand how Agile will affect and benefit them directly.  

Developers, on the other hand, probably wants to know if they will have interesting work, the opportunity to learn new things and the ability to make an impact on the company’s products.

a QA manager is probably interested in hearing how Agile helps enrich the QA profession.

The focus isn’t on Agile, its on business, as it should be.

The easiest way to find out what interests someone is to ask them.  When you meet, leave plenty of time for talk.  Motoring through a well-rehearsed Agile presentation usually doesn’t work.  A lot of times I’ll have slides with me, but they are a backdrop for the conversation.  I’ll refer to slides when it helps move the conversation along, but otherwise don’t use them.  You might want to forget slides altogether and just draw things on a whiteboard as necessary.  This technique is particularly useful with an individual or a small group.  

Take it One Step Further: Collect Data to Gain Insight

you’ll be most effective tailoring your message if you invest some time conducting data through a series of structured interviews. 

First, you’ll need a small set of questions prepared for the interviews.  Here are some examples. What is working with our current methodology? What’s not working with our current methodology? How do you think Agile would help our organization? What concerns do you have about Agile?

Interview a wide range of people: developers, testers, business analysts, managers, product managers, senior management, project managers and someone from finance. 

When you conduct the interviews, it is good to have one interviewer who has the primary responsibility for talking and the other person who has the primary job of taking notes.  You can switch off roles each interview so no one person gets stuck in either role.  Here’s how I typically start off.  

stories that people tell about the organization and make sure you write them down

I put all of the information we’d gathered into a mind-mapping program (Mindjet) and grouped like things together.

Make sure you keep interesting stories intact.  Specifics will help you make your cases

When there’s numerical data, people engage with a presentation in an entirely different way than they do when there are stories.  I find stories more effective, but do what works for you.

As an Agile evangelist, you job is to get Agile deployed effectively.  Along the way there are many people will be willing to go out of their way to help if you effectively speak to their interests and concerns.

We do a very good job - in general - teaching the skills. That is, teaching the team to run an iteration with a kickoff, demo and retrospective. Teaching test driven development. Some of us even do a very good job teaching the team to be pseudo-self-organizing by taking a socratic approach to coaching and standing back and letting the teams make their own mistakes and learn from them.

We even do a good job - in many ways - teaching the team the values of Agile development. If we are there long enough, the values come from diligent and disciplined application of the practices.

While starting at the team level with Scrum is often good, you often need to start with the product management team - that is, where product enhancements to be worked on are selected

Even when Scrum works at the team level, organizations very often report little impact to the bottom line.  While this is better than nothing (if the teams are happier, that's good), it usually doesn't justify a huge investment

in many contexts in which Scrum does not work readily, Scrum has no power to improve the context in which it is in.  In other words, the impediments that one must fix are often outside of the scope of what Scrum helps you do.

These impediments are often not even seen or if they are, are often viewed as "just the way it is."

certain Scrum attitudes often makes things worse

Scrum does little to let management to know how the team works or what impact management decisions have on the team

There is almost a religious zeal that Scrum tells you little of what to do

While SoS works well for certain types of work, it does not work well when the different teams have different motivations. 

the high failure rate is due to the fact that Scrum works in certain contexts but has little ability to change the contexts in which it doesn't work wel

One needs to pay attention to where to start as well as see how to change the context.  Separating the team from management doesn't help.  Focusing on only the team part of the value stream - giving little guidance both up and downstream of the team also doesn't help.  Lean provides guidance here (meaning Scrum with the aid of Lean could provide insights),

look into using Lean as a context for any improvement in your software development organization

While Scrum may be an appropriate choice in many circumstances, other methods may be better (e.g., Kanban Software Development).  Scrum's rapid ascension probably has more to do with its success in the places it easily fits.  Now that it is past the early adopter phase, we may see it having even a harder time as people attempt to scale it.

The reason there's been so much turnover of CIOs in the last ten years is because the end users – the CEOs, the CFOs and the division heads – are unhappy with the results. When IT professionals realize this, and realize that something like Agile gives them the opportunity to create better value for their businesses, then they're going to be a lot more willing to adopt it. I hope that development organizations are starting to see around that corner.

We WANT to go Agile. How do we overcome the skepticism at the CXO level?"

My recommendation would be "try it." Agile doesn't equal risk, but changing development methods does equal some risk

t can be a big deal to say: "I'm going to change our development methodology." It makes people sit up and want to dive into deep detail before getting on board. The question comes in the form of the old development methodology: "Let me see the high level plan and what the change will be in the deliverables and methodology over the next two years." This is exactly what you're trying to avoid by going to an Agile method.

try Agile on a few small projects, measure the results, talk to users about their satisfaction, and then readdress

nitiate the shift in the most change-prone areas first, and then work it backwards through the rest of the organization

It doesn't happen everywhere at all times, and it doesn't work in all areas. It's good to recognize that up front – that software development projects adapt to this easily, but an infrastructure project would have challenges with this approach. So, select a few areas that would naturally lend themselves to Agile, such as application development, gradually introduce it to these areas that need it most, and then measure results.

Again I'd say: "Try it." Agile transition is absolutely about organizational change. To win executive support we need to speak in terms of risk management, measurement and the bottom line.

Independent Software Vendors (ISV) -teams of teams who develop software for sale, including products like network management, supply chain management, mobile applications, etc. This segment now also includes the rapidly emerging Software as a Service (SaaS) vendors. Customers are external to the enterprise.

So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.

ultimate user (mobile device user) is fairly far removed from the major technologies

Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:

Embedded Systems Example - Symbian Software Limited

Clearly, the development of a mobile phone operating system is a highly technical endeavor

mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV

the development process does not lend itself quite so easily to the traditional, customer/user facing, agile Product Manager/Product Owner roles. However, the Product Owner role must still be successfully addressed in this highly technical context.

All our POs come from engineering teams and are senior engineers with product or customer experience.

one PO to two team mapping typically, rarely 3 teams, sometimes 1

IS/IT Examples

role/title of the Business Systems Analyst

is often a reasonably good fit for the Product Owner role.

In the larger IT shop, I have also seen the role filled by Project Managers

In many cases, the self-managing and team-based planning lightens the workload for the project manager in the agile enterprise, and they often have the domain knowledge, inclination and insights necessary to fulfill the Product Owner role. Therefore, many have the time, skills and inclination to fill this role.

In our case, our product owners are in IT. They are the liaison to the business and in many cases speak for the business

Our Business Systems Analysts in IT are filling the role of Product Owner. Their previous responsibility of documenting detailed business requirements and rules now falls to the entire team in the form of user stories and acceptance tests