Skip to main content

Home/ Agilesparks/ Group items tagged transformation

Rss Feed Group items tagged

Yuval Yeret

CIO Perspectives: A Conversation on Agile Transformation, Part 2 - 0 views

  • Part 2
  • The thinking is that IT is mission-critical, so let's not change things without giving it a lot of thought and a lot of consideration
  • The really hard part is around the people transformation - getting developers to work side-by-side with testers and users is a completely foreign concept.
  • ...8 more annotations...
  • 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.
Yuval Yeret

From the Agile Transformation Trenches: Culture Change with Pigs, not Chickens - 0 views

  • Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).
  • Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong
  • Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough.
  • ...3 more annotations...
  • Providing initial training is simply not enough. When the pressure is on, the temptation to return to previous ways of doing things is often too strong to resist. If technical leads are to work for you, they need on-going support and coaching, and a means by which they can support each other.  Good external coaches (expert chickens?) can help here.
  • Let the technical leads continue working on their projects. Some fail at the final hurdle by doing 1-3 above and then assigning or scheduling the technical leads to coach other projects, effectively turning them from pigs into chickens.
  • To summarize, if you can produce a change in the behavior of the lead pigs, the other pigs will, by definition, follow. However, pigs will not follow chickens for long because chickens are simply not pigs.
  •  
    Last month David Anderson wrote a two-part article on why agile transformation initiatives fail. David's suggestion to concentrate on cultural change reminded me of one of my favorite bits on process initiatives. From Peter Coad's book, Java Modeling in Color...
Yuval Yeret

Company-Wide Business Agility and the Soviets - 0 views

  • Tom Grant, a Forrester analyst who covers agile and product management, brought early results of his research on business agility to P-Camp. He has divided technology companies into An agile "vanguard" implementing first-wave improvements in their software development models, and Agile "transformation" companies making broad corporate-wide improvements in understanding customers and cross-departmental coordination.
  • "the end of Soviet-style development." He reminded us that Soviet five-year plans had little to do with the reality of hungry Russians and empty store shelves. In the same vein, technology companies with top-down command-and-control waterfalls tend to be unresponsive and overly optimistic. They often lack good market-sensing mechanisms or useful bottoms-up development metrics, so they routinely deliver unexciting products later than planned.
Yuval Yeret

Social, Agile, and Transformation: The ScrumMaster - A role or responsibility? - 0 views

  • So if they needed the ScrumMaster role filled, then this was something they were prepared to train and assign to either a project manager or possibly a technical lead. The consensus of this team was, if you found a project manager skilled enough to have a real technical dialog with the development team, then this person could be trained and perform the ScrumMaster role.
  • The Scrum Alliance published a survey that has some supporting evidence. Over 60% of the 1100 people that responded to the survey had nine or more years of industry experience, 15% of them had twenty or more years of experience, and 35% had Masters degrees. Also, of the people who responded, 22% were project managers and another 21% were either Managers or Directors. So my simple translation is that practicing ScrumMasters are managers (project or other) with significant (10+) years of proven experience. Training and assigning this role to experienced project managers or software development managers seems like a viable approach to have the responsibility filled and having a dedicated ScrumMaster separate from these roles may not be necessary.
Yuval Yeret

Tailor your Message To Gain Support for your Agile Initiative | Enabling Agility - 0 views

  • Connect Agile’s Benefits to your Company’s Priorities
  • aying that Agile is “better, faster, cheaper” may not be enough to cause a company to be willing to go through the often-painful process of cultural and process change.  You could implement Agile, but you could also try Six Sigma or Lean.  Saying that Agile is a general get-better remedy puts it in line with many other get-better methods.
  • f they don’t see a meaningful update from us, at least once a quarter, we’re going to get kicked out of the game.  We’ve all acknowledged that as we’ve gotten bigger, our processes have become more cumbersome and now is the time to do something about it.  Agile will give us the ability to regain that rapid pace of delivering innovations to market that we were know for in our early days.”
  • ...21 more annotations...
  • 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.
Yuval Yeret

Patterns and Anti-patterns in Enterprise Adoption - 0 views

  •  
    Amdocs people - Read and nod every sentence or so... nothing much new, but it would be nice not to fall into known pitfalls so much...
Yuval Yeret

Ideal Training for Enterprise-Scale Agility? « Scaling Software Agility - 0 views

  • training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach
  • for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal
  • all team practitioners receive a minimum of two days of agile training, (agile team training for the each team in the enterprise)
  • ...11 more annotations...
  • an additional day or so of training for specialized roles of Product Owner, Project/Release Manager, and Agile/Scrum Master
  • All other executives and managers are invited to attend an overview course on scaling software agility
  • Agile for Teams –Essential, team-based training in a two day workshop
  • philosophy, principles, and benefits of agility, agile methods, iterative and release framework, roles, agile technical practices, and agile management practices (Scrum)
  • Agile Release and Project Management at Enterprise Scale – For Project Managers, Release Managers, Program and Portfolio Managers who have responsibility for helping deliver the product(s) to the marketplace. Topics include differences between traditional and agile product management, iteration framework, multi-level release planning and tracking, the agile release train, planning and executing the release planning event, and measuring enterprise progress.
  • Agile Product Owner in the Enterprise – For team-based product owners/candidates who will become responsible for backlog management, story writing, and iteration and release planning, and who will also be involved in the planning and coordination of larger scale software systems of systems built by teams of teams.
  • The Agile Master In The Enterprise – For potential agile team leads/future Scrum Masters who will be coaching agile teams and who will interact with other teams as well. Topics include: process facilitation, enterprise agility, mastering the iteration, team roles, release planning and tracking, agile leadership, empowerment and conflict management, and integration Scrums.
  • Agile Product Manager in the Enterprise – For enterprise product managers with product, product line, portfolio and business unit responsibilities. Topics include: what’s so different about agile, backlog and prioritization, relationship to product owners, PM’s role in release planning and management, visioning and the product roadmap.
  • Scaling Software Agility – Best Practices for Large Enterprises – For executives and key stakeholders in support, distribution, quality, internal IT, HR and all others whose roles will be impacted by the substantive changes that enterprise agile engenders. Part I – overview of agility highlighting lessons learned from the most common and effective agile methods Part II – seven team best practices of agility that natively scale to the enterprise level Part III – seven organizational capabilities that companies can master to achieve the full benefits of enterprise scale agility
  • The team member doesn’t need a CSM course, but he does need to know how to work in an agile environment.
  • what are the engineering practices need to support agile development? I’ve found that if developers only have their existing tools and practices, then they will continue to specify and develop waterfall-style within the sprints.
Yuval Yeret

From the Agile Transformation Trenches: Borland Agile Assessment 2009 - 1 views

  • We measure progress in business-valued terms such as time-to-value, cost/benefit ratio and customer satisfaction.
  • There is no "score" to this assessment.  It is administered anonymously with results reported in aggregate.  This is a diagnostic tool to help us all reflect on our processes and identify ways to improve.  It cannot measure "improvement" from a previous assessment, only relative importance of potential improvements to our current situation.  
  • inally, this is not a competition.  The results will be most useful in helping you reflect on your current circumstances and establish priorities within your teams on areas of potential growth.
Yuval Yeret

Creating an Agile Culture to Drive Organizational Change - 1 views

  • It is critical that everyone has the same understanding of, and commitment to, the desired outcome: a business that is reliable through predictable technology processes that deliver business agility. To do this, there needs to be a management commitment to develop a focused, on-going practice around the pursuit of organizational maturity. As part of this, gaps in skills and capabilities should be identified and positive action – training, coaching, process improvement and tools deployment – taken in order to close the gap
  • the work force needs to understand the business drivers for Agility. They need to be challenged to improve their quality, improve their cycle times, to improve the frequency of releases and the value they deliver to the customer. They need to know how these things fit within the bigger picture and why improvement is their responsibility.
  • To change a culture it's important to recognize that every knowledge worker makes decisions and takes actions that affect the performance of the business. The culture in the organization is the reflection of those decisions and actions.
  • ...14 more annotations...
  • 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.
Yuval Yeret

Why agile transitions initiatives might fail : Jeffrey Palermo (.com) - 1 views

  • The executive makes a “vendor” or external “coach” responsible for the transition If you have handled the first risk and have defined success and success metrics, you likely will not find a vendor who will base his payment on your metrics.  After all, the metrics likely call for less project failure rate, faster response times, etc.  You probably can’t measure these things in less than a year if you really want objective metrics and not one optimized for short-term results at the expense of the longer term.  A vendor might want: # of people trained % of teams using an “agile” project management tool # of teams with an embedded “agile champion” # of successful iterations It is really easy to accomplish the above metrics and still not make any material change in the organization.  I have worked with a client that did something similar to the above.  Most of the teams starting using some new Scrummy project management web application for project tracking.  They declared that monthly status meetings were now iterations.  They declared a member of the team to be the Scrummaster (and sent that person to training).  Overall, the same organizational problems persisted.  Vendors cannot produce real change in an organization unless the organizations executive leadership alters the culture in a meaningful way.
1 - 15 of 15
Showing 20 items per page