PEARL II : Agile Project Management ensures a value-driven approach that allows to deliver high-priority, high-quality work . Agile Project Management establish the project’s context. It enables to manage the team’s environment, encourage team decision making and promote autonomy whenever possible. Agile Project Management expects the best out of people, elevates the individual and gives them respect. It helps foster a team culture that values people and encourages healthy relationships.
Introduction
Agile_leadership
One of the common misconceptions about agile processes is that there is no need for agile project management, and that agile projects are self reliant . It is easy to understand how an agile process’ use of self-organizing teams, its rapid pace, and the decreased emphasis on detailed plans lead to this perception. In a recent egroup, a project manager at a company that was implementing agile had been moved to another area because, “…agile doesn’t require project management capability.”
However, The truth is agile processes still require project management.
Agile methodology does not clearly define the role of manager but instead defines similar roles like coach/facilitator who performs the role of Agile Project manager.
An Agile project manager understands how the Agile delivery engine works – that the concept is based on self-organization and undisturbed activity. In addition, he or she has the ability to manage business needs and goals, requirements, organizational models, contracts and overarching as well as ‘rolling’ planning methods,’
Agile Project Manager
In Agile transitions, there is a need for an Agile project manager when the project and delivery engine is exposed to complexity factors – as in, for example, when several teams collaborate on a release from a number of international locations.’ Requirements themselves may also lead to complexity such as when teams are faced with regulatory requirements or the need for extremely rapid alteration cycles. Other complexity factors are outsourcing and procurement – that is, the purchase of various services from multiple providers – or when a company starts too many projects at the same time resulting in staff having so much to do that nothing gets done.
‘Several of these complexity factors exist in many of the companies and they have a cumulative effect. Agile project managers can achieve great things in such complex conditions by designing a comprehensive project environment providing oversight and structure. Agile contracts may be a valuable component of the project environment.
The Agile fixed price is a contractual model agreed upon by suppliers and customers of IT projects that develop software using Agile methods. The model introduces an initial test phase after which budget, due date, and the way of steering the scope within the framework is agreed upon.
This differs from traditional fixed-price contracts in that fixed-price contracts usually require a detailed and exact description of the subject matter of the contract in advance. Fixed price contracts aim at minimizing the potential risk caused by unpredictable, later changes. In contrast, Agile fixed price contracts simply require a broad description of the entire project instead of a detailed one.
In Agile contracts, the supplier and the customer together define their common assumptions in terms of the business value, implementation risks, expenses (effort) and costs. On the basis of these assumptions, an indicative fixed price scope is agreed upon which is not yet contractually binding. This is followed by the test phase (checkpoint phase), during which the actual implementation begins. At the end of this phase, both parties compare the empirical findings with their initial assumptions. Together, they then decide on the implementation of the entire project and fixate the conditions under which changes are allowed to happen.
Further aspects of an Agile contract are risk share (both parties divide the additional expenses for unexpected changes equally among themselves) or the option of either party leaving the contract at any stage (exit points).
Jim Highsmith, one of the originators of the Agile Manifesto and a recognized expert in agile approaches, has defined agility in project management by the following statements:
“Agility is the ability to both create and respond to change in order to profit in a turbulent business environment,” and “Agility is the ability to balance flexibility and stability” .
In contrast with traditional project methods, agile methods emphasize the incremental delivery of working products or prototypes for client evaluation and optimization. While so-called “predictive” project management methods assume that the entire set of requirements and activities can be forecast at the beginning of the project, agile methods combine all the elements of product development, such as requirements, analysis, design, development and testing — in brief, regular iterations. Each iteration delivers a working product or prototype, and the response to that product or prototype serves as crucial input into the succeeding iterations.
Agile theory assumes that changes, improvements and additional features will be incorporated throughout the product development life cycle, and that change, rather than perceived as a failing of the process, is seen as an opportunity to improve the product and make it more fit for its use and business purpose.
The Need for Agile Project Management
Project management is critical to the success of most projects, even projects following agile processes. Without management, project teams may pursue the wrong project, may not include the right mix of personalities or skills, may be impeded by organizational dysfunction, or may not deliver as much value as possible. There are initiatives to formalize these management responsibilities.
When it comes to agile project management roles, it’s worth noting that most agile processes – Scrum in particular – do not include a project manager. Without a specific person assigned, agile “project manager” roles and responsibilities are distributed among others on the project, namely the team, the ScrumMaster and the product owner.
Waterfall-vs-Agile
Agile Project Management and Shared Vision
For a team to succeed with agile development it is essential that a shared vision be established. The vision must be shared not just among developers on the development team but also with others within the company. Most plan-driven processes also advocate the need for a shared vision; however, if that vision isn’t communicated or is imprecise or changing, the project can always fall back on its detailed (but not necessarily accurate) lists of tasks and procedures. This is not the case on an agile project and agile project participants use the shared vision to guide their day-to-day work much more actively.
The formation of the project vision is not the responsibility of the agile project manager; usually the vision comes directly from a customer or customer proxy, such as a product manager. The project manager, however, is usually involved in distilling the customer’s grand vision into a meaningful plan for everyone involved in the project. Rather than a detailed command-and-control plan based on Gantt charts, however, the agile plan’s purpose is to lay out an investment vision against which management can assess and frequently adjust its investments, lay out a common set of understanding from which emergence, adaptation and collaboration occur, and establish expectations against which progress will be measured. The project manager works with the customer to layout a common set of understanding from which emergence, adaptation and collaboration can occur. The agile project nurtures project team members to implement the vision. The agile project manager understands the effects of the mutual interactions among the project’s parts and steers the project towards continuous learning and adaptation on the edge.
Scope of Agile Project Management:
Agile Process
In an agile project, the entire team is responsible in managing the team and it is not just the project manager’s responsibility. When it comes to processes and procedures, the common sense is used over the written policies.
This makes sure that there is no delay is management decision making and therefore things can progress faster.
In addition to being a manager, the agile project management function should also demonstrate the leadership and skills in motivating others. This helps retaining the spirit among the team members and gets the team to follow discipline.
Agile project manager is not the ‘Head’ of the software development team. Rather, this function facilitates and coordinates the activities and resources required for quality and speedy software development.
Agile Project Management and Obstacles
Most agile processes prescribe a highly focused effort on creating a small set of features during an “iteration” or “sprint” after which the team quickly regroups and decides on the set of features for the next iteration or sprint. While an iteration is ongoing the team members are expected to focus exclusively on the current iteration.
While this sharp focus leads to greater productivity during the current iteration it can cause a bit of a billiard-ball effect as the conclusion of one iteration can bounce out the start of the next. A project manager who spends a small amount of time looking forward at the next iteration is an excellent buffer against this effect. For example, many organizations have travel restrictions that require plane tickets to be purchased two weeks in advance. If a team could benefit from having a remotely located employee on site during the coming iteration the time to plan for that is during the current iteration.
Another type of obstacle may be a team member.
While agile processes such as Extreme Programming and Scrum rely on self-organizing teams, an agile project manager cannot simply turn a team loose on a project. The agile manager must still monitor that corporate policies or project rules are followed. Participation on an agile team does not turn all developers into model employees. In most cases the team itself will employ some form of sanctioning on an employee who is not working hard enough or is exhibiting other performance or behavior problems. However, in the most severe cases the collective team usually cannot be the one to terminate or officially reprimand an employee. Performance feedback can always be expressed in terms of team views of the individual’s contribution to the team But if a counseling or coaching session is necessary it is usually best when between just the project manager and the team member.
Businesses must evolve to use flexible practices such as agile project management, to prevent significantly slowing down the productivity of their business and risking their profits.
Round Table Event at hosting and colocation firm UKFast’s Manchester office in Jan 2014
UKFast is one of the UK’s leading managed hosting and colocation providers, supplying dedicated server hosting, critical application hosting, and cloud hosting solutions. it fully own, manage and operate its ISO-accredited data centre complex, which offers over 30,000 sq ft of enterprise-grade facilities for collocating IT equipment.
All of its hosting solutions are designed to help businesses grow, with 24/7/365 UK-based support and dedicated account management as standard. It is exceptionally proud of the standard of service it gives to clients and believe it’s what really sets them apart from other providers.
Old fashioned firms must encourage the ownership and innovation needed to create a happier, more modern workplace or face the consequences of being left behind by companies that do.
That’s the view of six project management experts who gathered at a roundtable event to discuss whether old management techniques have become nothing more than a hindrance to businesses and whether traditional practices still have a role in the workplace.
Lawrence Jones, CEO of hosting and colocation firm UKFast, believes a fun work environment, bolstered by flexible and collaborative project management techniques, results in happier people within the company.
Jones said: “I believe an enjoyable workplace is often a productive workplace. A fun and friendly work ethic is the route to economic recovery and adopting agile project management techniques comes hand in hand with this.
“Having a culture in place that encourages collaboration not only motivates the team, it also means that clients receive a better, faster service that isn’t weighed down by traditional box-ticking procedures.”
Agile project management focuses on the continuous improvement, team input and delivery of essential quality products. By breaking up a project into “sprints” – worked on by different team members simultaneously – agile encourages collaboration and integration unlike other, traditional methods that are often rigidly sequential.
Ninety per cent of respondents in the 7th Annual State Agile Development survey cited that agile improved their ability to manage changing priorities compared to waterfall, while the top two other benefits listed were increased productivity (85 per cent) and improved project visibility (84 per cent).
Ian Carroll, Principal Consultant at ThoughtWorks agrees said: “It is about doing a good job. Nobody comes into work to do a bad job. Agile project management requires cross-functional teams, which result in happier people coming together to make for a much happier work place.”
Clare Walsh, Digital Delivery Director from Redweb believes that teamwork created by agile project is vital for a company’s success.
Walsh said: “It’s about creating that sense of involvement. When somebody really feels involved, they can own it. That’s the whole point of agile, that the team feel some kind of ownership about what they are creating. It’s about empowerment and people feeling like they have the ability to make decisions.”
Beccy Weeks, IS Manager at Saint Gobain Building Distribution has seen agile bring big benefits to her company, including improvements to the integration of new staff members.
She said: “Agile prevents isolation. We’ve found that it’s easier to bring new people into the team as they get on straight away. They are immediately communicating; they feel part of the team and can join in with the banter. They are integrated much quicker using the agile approach, rather than the waterfall management.”
James Cannings, Chief Technical Officer at MMT Digital believes the culture within his workplace has positively transformed due to the change to agile management.
He said: “Agile has completely transformed the culture of my agency over the last two years. We were proud of the culture we had, but I now feel bad in the sense of how we treated the developers who just worked from one project to the next. It was quite a sort of hierarchal structure. Agile now creates a fun environment, which brings the whole team together.”
Mark Kelly, Digital and Social Media Marketing Consultant regrets the management approach he previously undertook.
He said: “The developers and designers were treated like mushrooms in the waterfall approach, not knowing what the guys next to them were doing. The agile approach therefore most certainly provides visibility for everyone on the team.”
The experts gathered at hosting and colocation firm UKFast’s Manchester office to debate the topic of project management and how businesses can implement new techniques to the best effect. Here are their top tips:
- Don’t forget, agile is a means to an end rather than an end point itself
- How you visualise the world dominates how we perceive the world so having a card wall or something to illustrate tasks can really help teams
- Agile isn’t the best for building a skyscraper but great for a fast-paced software development – it could just be about design and development rather than the whole project
- It’s about creating a culture of fun as well as ensuring a fast time to market.
Agile Project Management and Organizational Dysfunction
Many companies have at least one dysfunctional area. This may be the “furniture police” who won’t let programmers rearrange furniture to facilitate pair programming. Or it may be a purchasing group that takes six weeks to process a standard software order. In any event these types of insanity get in the way of successful projects. One way to view the project manager is as the bulldozer responsible for quickly removing these problems.
The Scrum process includes a daily meeting during which all team members are asked three questions. One of these questions is, “What is in the way of you doing your work?” The agile project manager takes it on himself to eliminate these impediments. Ideally, he or she becomes so adept at this that impediments are always removed within 24 hours (that is, before the next daily meeting).
Participate in enough agile projects and you begin to hear the same impediments brought up time after time. For example:
- My ____ broke and I need a new one today.
- The software I ordered still hasn’t arrived.
- I can’t get the ____ group to give me any time and I need to meet with them.
- The department VP has asked me to work on something else “for a day or two”
The project manager is responsible for optimizing team productivity; this means it’s his responsibility to do whatever possible to minimize obstacles. Most organizations will not want every developer calling the ordering department to follow up on delivery dates for software. Similarly, a project manager who can know when to push the IT manager for quick setup of a new PC and when not to push (perhaps saving a favor for later) will be more effective than every programmer calling that same IT manager.
Agile Project manager may need to Work out resource movement with a realistic transition plan with minimum impact on business.
Agile Project Management and Politics
Politics are at play in almost every organization. Most organizations have only limited funds that may be applied across a spectrum of competing projects and new project ideas. Projects compete for budget dollars (team size, tools, etc.), personnel (everyone wants the best programmer), resources (time or access to the large database server), and attention from higher level managers. Too many projects fail for political reasons. A project manager uses the various agile mechanisms to minimize politics and keep everything visible and obvious.
For instance, the project manager works with the customer to ensure that the product backlog (Scrum) or stories (XP) is visible and everyone understands that it directs the team to the most profitable and valuable work possible. The project manager uses product increments and demonstrations of working functionality to keep everyone aware of real progress against goals, commitments, and visions, thereby minimizing opportunities for rumors, misinformation, and other weapons of political maneuvering. Working with the customer, the project manager helps the customer and organization to value results instead of reports.
Agile Project Leadership in Agile Project Management
Agile project leadership is key parameter in ensuring the project success within constraints and boundaries of the organization.
There are many leadership models discussed in popular leadership literature from Jim Collins to John C. Maxwell. Most of the models talk about leadership at organizational level. The agile project leadership has narrow canvass – which is ensuring successful agile projects, successful agile adoptions. The leadership levels applicable to Agile project management are Collaborative Leadership, Servant Leadership and Trans formative leadership in Levels 2,3,4 respectively. Level 1 – Positional leadership is not applicable to agile project management canvas.
Collaborative leadership.
Here the leader gets things done through collaboration. Relationship is the key characteristic of this level. A collaborative leader builds a strong relationship with the people. Leaders at this level care for their people. They support their people and motivate them constantly. The true collaborative nature of leadership stitches the bond between the leader and the team. Many agile teams experience collaborative leadership. An agile coach builds a strong relationship among the scrum team through his coaching and facilitation skills.
Servant Leadership
Here the leader serves first to lead consequently. Serving is the key idea in this level.
The term “Servant Leadership” was coined by Robert K. Greenleaf in “The Servant as Leader”, an essay that he first published in 1970. In his essay, he said “The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve
first. Then conscious choice brings one to aspire to lead.” The idea of servant leadership can be traced to the 4th century B.C. Chanakya in his book Arthashastra wrote that a king [leader] is a paid servant and enjoys the resources of the state together with the people.
A servant leader serves the team unequivocally. Leaders at this level gain the respect through serving the team. They listen to the team; they take cues from observing the team and empower them in decision-making. Serving is a leadership attitude and a mindset. Agile coaches are expected to have this attitude.
Robert Greenleaf has introduced the concept of the “servant-leader.”1 Perhaps this is the most appropriate way of thinking of the agile project manager. On an agile project the project manager does not so much manage the project as he both serves and leads the team. Perhaps this is one reason why, anecdotally, it seems much more common to see an agile project manager also function as a contributor to the project team (whether writing or running tests, writing code or documentation, etc.).
Plan-driven software methodologies use a command-and-control approach to project management. A project plan is created that lists all known tasks. The project manager’s job then becomes one of enforcing the plan. Changes to the plan are typically handled through “change control boards” that either reject most changes or they institute enough bureaucracy that the rate of change is slowed to the speed that the plan-driven methodology can accommodate. There can be no servant-leadership in this model. Project managers manage: they direct, administer and supervise.
Agile project management, on the other hand, is much more about leadership than about management. Rather than creating a highly detailed plan showing the sequence of all activities the agile project manager works with the customer to layout a common set of understandings from which emergence, adaptation and collaboration can occur. The agile project manager lays out a vision and then nurtures the project team to do the best possible to achieve the plan. Inasmuch as the manager represents the project to those outside the project he or she is the project leader. However, the project manager serves an equally important role within the project while acting as a servant to the team, removing their impediments, reinforcing the project vision through words and actions, battling organizational dysfunction, and doing everything possible to ensure the success of the team. The agile project manager is a true coach and friend to the project teams.
With “light touch” control, agile project managers realize that increased control doesn’t cause increased order; they approach management with courage by accepting that they can’t know everything in advance, and relinquish some control to achieve greater order.
Throughout the project, the project manager identifies practices that aren’t followed, seeks to understand why; and removes obstacles to their implementation. Used thus, for example , the agile practices provide simple generative rules without restricting autonomy and creativity
Trans-formative Leadership
Transformative in nature. Here the leader transforms others as leaders. The key characteristic of this level is transformation. Transformative leaders lead by example; work through organizational constraints well; they glide over organizational politics; they stretch the organizational boundaries and lead the team to newer areas. Transformative leaders develop others to reach levels 3 and 4. They have big picture in mind and think global always.
Dysfunctions of Teams
Teams go through many levels of maturity. Bruce Tuckman describes the four stages of Forming, Storming, Norming and Performing. Patrick Lencioni takes us though the 5 Dysfunctions of a Team. Teams just don’t start day one as a productive, self-organizing team. They go through a process. There are bumps and challenges. The Agile Project Manager is responsible for getting the team through these phases with as little pain as possible. Even after a team gets to a mature stage, the slightest change can revert the team to a former, less mature stage. team gets to a mature stage, the slightest change can revert the team to a former, less mature stage.
- Inception or planning activities
- Informal social events
- Team building events
- Remember the Future activity
- Retrospectives
- Team Health checks
People are a key part to the success of any project. No matter what organizational model we invent, if people are not engaged it won’t work. Motivation, engagement, ownership and self-organization are the core values of an agile mindset. Agile project managers’ first concern should be team morale. If team members are good professionals they’ll know how to sort out any situation while in the right mood. If they’re not good professionals… we have a bigger problem and it is not going to be solved by agile techniques or any other solution.
Tossing more process to an already dysfunctional team is not going to help out, it will only add to the mess. The key to success is doing more with less: less process, less people, less rules, less time to get things done. Let people do what they’re here for – design and build – and free them from as much paperwork and red-tape as possible.
Any critical view needs an alternative proposal, so here is recipe to avoid the liturgical trap and encourage actual continuous improvement:
- Always be mindful, question the necessity of the process: A good way to test how valuable a ceremony or practice is for a team, especially if detecting a smell, is to make it voluntary. If team members find it valuable they’ll perpetuate the practice and all will feel its usefulness. If they abandon the practice, it’s time to look for alternatives. That is self-organization.
- Be flexible and try new things, in their fullness: Some of the agile practices need time and training to actually work. It’s difficult at the beginning and people resist change. As a team, they can be disciplined, when they decide to try out a practice, adopt it in its completeness, with full understanding of it for a period of time. They can then incorporate it in process based on its proven effectiveness.
- Check on team morale often: Using retrospectives, one-on-one conversations, anonymous polls or whatever other way, Agile PM ask people what they need to get things done. Find out their aspirations and expectations and take steps to increase motivation.
- Find your balance: When motivation fails, discipline and good practices help. But we cannot rely only on discipline to achieve success, as discipline has a price we pay in terms of team morale. Motivation has the same effect as discipline without paying this price.
Responsibilities of an Agile Project Manager:
Following are the responsibilities of an agile project management function. From one project to another, these responsibilities can slightly change and become interpreted differently.
- Responsible for maintaining the agile values and practices in the project team.
- The agile project manager removes impediments as the core function of the role.
- Helps the project team members to turn the requirements backlog into working software functionality.
- Facilitates and encourages effective and open communication within the team.
- Responsible for holding agile meetings that discusses the short-term plans and plans to overcome obstacles.
- Enhances the tool and practices used in the development process.
- Agile project manager is the chief motivator of the team and plays the mentor role for the team members as well.
Fowler (2002) and Blotner (2003) suggest that a manager can and should help the team be more productive by offering some insight into the ways in which things can be done in an agile environment.
Grenning (2001) observed that having senior people monitor the team’s progress at a monthly design-as-built review meeting accelerated the development process while lowering the number of bugs.
Adaptive Teams
Another major premise is the ability to adapt – hence the Agility. Delivering features early may not be enough when the goalpost you are shooting for moves, but shorter feedback and corrective cycles means that you can correct the course of action early and able to respond to emerging market opportunities.
Obviously, there is no magic bullet, the journey would still have to be made, with team doing all that is necessary for the application to rise – what is different though, is that team will not be in the dark about how they are going to get to the end, customers will not have to wait till the end to touch and feel the product, there won’t be any grand change control processes if the goalpost keeps moving, instead business will be able to change their minds and team will be able to adapt, learn and produce valuable piece of software along the way.
To ensure delivery of a “non-obsolete” solution, it is important that any changes to project requirements are handled proactively by making necessary adjustments to the development process (process dimension) and the development team (people dimension).
Agile Project Management at Salesforce.com
Salesforce.com has recently completed an agile transformation of a two hundred person team within a three month window. This is one of the largest and fastest “big-bang” agile rollouts. It focused on creating self-organizing teams, debt-free iterative development, transparency and automation.
Salesforce.com is a market and technology leader in on-demand services. it routinely process over 85 million transactions a day and have over 646,000 subscribers. Salesforce.com builds a CRM solution and an on-demand application platform. The services technology group is responsible for all product development inside Salesforce.com and has grown 50% per year since its inception eight years ago, delivering an average of four major releases each year. Before agile rollout it had slowed to one major release a year. The agile rollout was designed to address problems with its previous methodology:
-
Inaccurate early estimates resulting in missed feature complete dates and compressed testing schedules.
-
Lack of visibility at all stages in the release.
-
Late feedback on features at the end of our release cycle.
-
Long and unpredictable release schedules.
-
Gradual productivity decline as the team grew.
Before the agile rollout the R&D group leveraged a loose, waterfall-based process with an entrepreneurial culture. The R&D teams are functionally organized into program management, user experience, product management, development, quality engineering, and documentation. Although different projects and teams varied in their specific approaches, overall development followed a phase-based functional waterfall. Product management produced feature functional specifications. User experience produced feature prototypes and interfaces. Development wrote technical specifications and code. The quality team tested and verified the feature functionality. The documentation team documented the functionality. The system test team tested the product at scale. Program management oversaw projects and coordinated feature delivery across the various functions.
its waterfall-based process was quite successful in growing our company in its early years while the team was small. However, the company grew quickly and became a challenge to manage as the team scaled beyond the capacity of a few key people. Although they were successfully delivering patch releases, the time between its major releases was growing longer (from 3 months to over 12). Due to fast company growth and lengthening of release cycles, many people in R&D had not participated in a major release of main product. Releases are learning opportunities for the organization. A reduction in releases meant fewer opportunities to learn. This had a detrimental affect on morale and on ability to deliver quality features to market.
Transition Approach
An original company founder and the head of the R&D technology group launched an organizational change program. He created a cross-functional team to address slowing velocity, decreased predictability and product stability. This cross-functional team redesigned and rebuilt the development process from the ground up using key values from the company’s founding: KISS (Keep it Simple Stupid), iterate quickly, and listen to customers. These values are a natural match for agile methodologies.
It was very important to position the change as a return to core values as a technology organization rather than a wholesale modification of how they deliver software. There were three key areas that were already in place that helped the transition: 1) the on-demand software model is a natural fit for agile methods; 2) an extensive automated test system was already in place to provide the backbone of the new methodology; and 3) a majority of the R&D organization was collocated.
One team member wrote a document describing the new process, its benefits and why they were transitioning from the old process. They led 45 one-hour meetings with key people from all levels in the organization. Feedback from these meetings was incorporated into the document after each meeting, molding the design of the new process and creating broad organizational buy-in for change. This open communication feedback loop allowed everyone to participate in the design of the new process and engage as an active voice in the solution. Two key additions to the initial paper were a plan for integrating usability design and clarification on how much time we needed for release closure sprints.
At this point, most literature recommended an incremental approach using pilot projects and a slow roll out. They also considered changing every team at the same time. There were people in both camps and it was a difficult decision. The key factor driving us toward a big-bang rollout was to avoid organizational dissonance and a desire for decisive action. Everyone would be doing the same thing at the same time. One of the key arguments against the big-bang rollout was that they would make the same mistakes with several teams rather than learning with a few starter teams and that they would not have enough coaches to assist teams every day. One team in the organization had already successfully run a high visibility project using Scrum . This meant that there was at least one team that had been successful with an agile process before they rolled out to all the other teams. They made a key decision to move to a “big-bang rollout” moving all teams to the new process rather than just a few.
Some of the key wins since the rollout have been:
-
Focus on team throughput rather than individual productivity
-
Cross-functional teams that now meet daily
-
Simple, agile process with common vocabulary
-
Prioritized work for every team
-
A single R&D heartbeat with planned iterations.
-
User stories & new estimation methods
-
Defined organizational roles – ScrumMaster, Product Owner, Team Member
-
Continuous daily focus on automated tests across the entire organization
-
Automation team focused on build speed & flexibility
-
Daily metric drumbeats with visibility into the health of products and release
-
Product line Scrum of Scrums provide weekly visibility to all teams
-
R&D-wide sprint reviews and team retrospectives held every 30 days
-
Product Owner & ScrumMaster weekly special interest groups (SIGs)
-
A time-boxed release on the heels of biggest release ever
-
Reduction of 1500+ bugs of debt
-
Potentially release-able product every 30 days
Although they are still learning and growing as an organization, these benefits have surpassed our initial goals for the rollout. Some areas that they are still focusing on are: teamwork, release planning, bug debt reduction, user stories and effective tooling.
Pearls of Wisdom 