WEBINAR – The Different Agile Approaches: First (XP, Scrum) and Second (Lean/Kanban) Generation Methods
Get an overview of Agile approaches starting with eXtreme Programming (XP) & Scrum and then hear about Lean-Agile and its team oriented Kanban for software process.
Early Agile methods have been overly-team centric and have eschewed management. While second generation Agile methods build on a decades old history of Lean thinking and have extended agility in three ways that are not only required for an enterprise engagement but also for creating synergies that improve Agile at the team level:
- Extending the Team to across the Enterprise
- Extending Individual skill sets to Systemic Thinking
- Extending the Worker to include Management
Webinar Recording can be listened to click here
TOPICS DISCUSSED will include:
- How the new Agile team methods of Kanban and Scrumban fit into the larger picture of enterprise, management and systems.
- Why the low success rate at the business level is a direct result of first Agile generation methods’ focus on the team while eschewing systems thinking.
- The different Lean-Agile Methods
- Lean-Agile and Kanban address many of the issues that late adopters to Agile have intuitively felt are necessary for a mature organization. While many of these have been sometimes ridiculed by early agile methods, these concerns are a part of Lean-Agile / Kanban.
SPEAKER: Alan Shalloway is the founder and CEO of Net Objectives. With almost 40 years of experience, Alan is an industry thought leader. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in Lean, Kanban, Scrum, Design Patterns, and Object-Orientation. Alan has developed training and coaching methods for Lean-Agile that have helped his clients achieve long-term, sustainable productivity gains. He is a popular speaker at prestigious conferences worldwide. He is the primary author of Design Patterns Explained: A New Perspective on Object-Oriented Design, Lean-Agile Pocket Guide for Scrum Teams, Lean-Agile Software Development: Achieving Enterprise Agility and is currently writing Essential Skills for the Agile Developer. He has a Masters in Computer Science from M.I.T. as well as a Masters in Mathematics from Emory University.
PDU’s: 1…….(PDU info is provided in the recording)
COST: Free
.
Proven, Practical Tactics For Agile IT Release Management – (Part 2: DEFINITIONS AND TRIAGE)
OVERVIEW:
This article is the second in a series of five which explain how an IT organization delivered a release management process that exceeded its management’s expectations and provided a foundation for continued success. The series includes:
1. How did we get here – THE CONTEXT
2. First solution steps – DEFINITIONS AND TRIAGE
3. Intake and Release Planning – THE CORE SOLUTION
4. Production Change Control – FINAL QUALITY CONTROL
5. Metrics and Insights – LESSONS LEARNED
SUMMARY:
Many Information Technology organizations flounder when they are tasked to understand, organize and implement numerous changes to the system and application software serving their clients and end customers over a period of several years. This second article focuses on the very first steps of the solution I developed for the Release Management consulting engagement. Please refer to the first Article – THE CONTEXT for a full discussion of the problem domain and organization. What was the secret sauce that made Release Management a success? The answer begins with core problem analysis, proposed solutions and a triage effort.
CORE PROBLEM ANALYSIS:
The company and its IT department clearly wanted a solution implemented that avoided historical mistakes. As a retained consultant, I conducted a series of one-on-one interviews, examined remnants of Change Control documents from a predecessor, investigated commercial off-the-shelf packages for both processes and operational tracking, and discovered the following core problems.
- Problem #1 – What Trees are in this Forest? A substantial source of confusion and discussion involved defining the scope of what things should be controlled under the umbrella of Release Management and Change Control. There were divergent opinions about whether to include/exclude major projects, infrastructure changes from operations, bug fixes, hardware changes, Customer service changes, emergency patches, etc. As with most debates within IT, the stakeholders frequently used similar terms to mean very different things. Very specific language needed to be written, socialized and implemented that reduced this ambiguity and confusion.
- Problem #2 – Who is Responsible for What? Projects were very clearly controlled end-to-end by Project Managers, and at any given time the 4 PMs would have 2-5 projects underway. These generally covered scope for multiple applications and multiple person-months of programming effort. Beyond that good start, Client Change Requests, Bug Fixes, Operations infrastructure changes, Customer service changes (move/update/fix my workstation) and emergency patches had no one role identified for control, communications and accountability throughout their life span. The IT assembly line for such work was disjointed at best and lacked fundamental structure. The role of Release Manager itself was undefined, with various stakeholders holding unique viewpoints on the scope of the assignment.
- Problem #3 – How To Introduce Order Upon Chaos? This was a very critical concern, as the inflow of new requests from the business could not be halted, due to political and practical matters. If the organization knew tactically where it stood on Monday for every item, by Wednesday the landscape had changed, and priorities for older work were being adjusted on-the-fly, either overtly or covertly by business leadership.
- Problem #4 – How Frequently Should We Release Change Packages? A practical concern was whether IT should embark on weekly, biweekly, monthly, quarterly or other frequency of planned production software change. The frequency of change would end up driving the timing of the real-world series of gates and meetings necessary for control and adjustment. The first solution proposal entailed purchasing a complete software application and documentation package from a market leader that promised to cover the full scope of their interests. The alternative proposal was founded upon a low level of automation, and a high degree of inter-personal collaboration to achieve similar ends.
CONCLUSION / TRANSITION
The CIO, facing this situation, agreed to allow the Manager for Project Management and Analysis to contract for a resource to implement Release Management (Version 2). The CIO believed that she could deliver better results to her constituency by implementing change in a series of well-understood application package upgrades at regular intervals. She also wanted to take back to her peers a plan that they could understand and use to directly influence the order of implementation for their changes. The Manager of PM retained me as the Release Manager with the mandate to institute the processes and controls needed, and engaging all IT staff and VPs in business departments as needed for success. The rest, they say, is “agile” history. To learn what it really takes, our story continues next with DEFINITIONS AND TRIAGE.
Definitions
I will remark on Definitions first, because the management team needed to ground itself and communicate in a consistent fashion about the key objects and controls with Release Management processes.
Problem #1 – What Trees are in this Forest? – SOLUTION:
We took the perspective that anything that is planned to change the configuration of the production computing environment within the controlled data center and network configurations was subject to Release Management processes. As a result, we included:
· Application software changes requested by clients or from IT itself (re-factoring, etc)
· Application software fixes that were “not immediately damaging” clients’ business
· Each software change package from projects (projects typically had more than one release package over several months)
· Network or server infrastructure upgrades (OS, DBMS, middleware, hardware, etc.)
We excluded from Release Management processes:
· Customer Service requests (fix/move my workstation, office moves, etc)
· Emergency production software application fixes (fix it now)
This last exclusion was troublesome, but necessary. We assigned total responsibility for managing the emergency fixes to the Software Development Manager, and set an overall target to keep these to fewer than 5% of the total changes made into production. (We tracked the numbers, but didn’t stand in the way). The practical outcome of these agreements was that each individual thing included in Release Management was a Change Request, to be initiated with a simple form. Each would be assigned a unique Number (and key attributes) and controlled in immediate form by an Excel spreadsheet updated and distributed by the Release Manager.
Problem #2 – Who is Responsible for What? — SOLUTIONS:
- Single Point of Contact (SPOC) The organization had a good model of behavior and accountability for projects, but there was disjointed accountability for all the other Change Request types. To solve this, we defined a role called the Single Point of Contact (SPOC). The role was accountable for conveying the requirements, correct status of IT progress, and sponsoring the Change Request for its ultimate release to production. The SPOC was individually accountable for telling our clients the timing and impact of the implementation of a change, so that our clients were adequately prepped for a release. The assignments to this role were expected to last for the duration of the Change Request, as opposed to the previous pattern of shifting responsibility. As a practical matter, the SPOC assignments for 75% of the Change Requests fell into the Project Manager/Business Analysis team.
- Architecture Review Board (ARB) The IT organization had a defined group called the Architecture Review Board (ARB) which convened to assess the technical and organizational impact and risks of major changes to the environment. This group consisted of the 5 IT Managers, the Applications Architect and the Operations Architect, and occasionally the CIO. As part of our definitional work it was determined that this group would exercise an expanded role – to quickly and routinely review each incoming change request. The Release Manager was added to the Board. This board was the “neck of the funnel” for all new items and through discussion, they determined rough size, priority, and impacts. The ARB also made the specific assignment of a SPOC to each new Change Request. More on the role of the ARB is covered in Article Three- Intake and Release Planning.
- Release Planning Group (RPG) The primary organizational element that needed to be set in place was a new group titled Release Planning. This team, facilitated by the Release Manager, met with great discipline and regularity to organize, re-organize, and commit to a comprehensive, concrete order of implementation for all Change Requests. While this sounds straightforward on paper, remember that the context for this role was to organize +/- 325 Change Requests into a series of planned releases – and do this repeatedly as new things got added each week. This was a puzzle with ever-moving parts. The Release Planning Group consisted of the 5 IT Managers and the Release Manager. The Release Manager published the current Release Schedule as an outcome of each of the group’s meetings.
- Change Control Board (CCB) This group was chaired by the Configuration Management leader, and had the responsibility to review and approve or defer the completed Change Requests for implementation in production. The Operations Manager and QA Manager played strong roles within this forum. The SPOCs for each Change Request were questioned for preparedness items, including the advance notification of the client communities. The CCB made a consensus decision on each Change Request and the outcome of these decisions allowed the Configuration Management Team to prepare the scripts and code packages for production upgrades.
Problem #3 – How To Introduce Order Upon Chaos?-SOLUTION
This fundamental problem afflicts all business organizations. Customer requirements constantly change in nature, new ones are added, and old ones wither yet refuse to die. Progress on the production line in IT is swift, stuttering, under-resourced, or overwhelmed. Managers independently made decisions from their own perspective of the best interests of the company. Frequency of change was sporadic. To introduce order, the Release Manager defined a disciplined business cycle for Release Management Processes. The business cycle was a repetitive set of scheduled meetings of the Architectural Review Board, Release Planning Group, and Change Control Board that would be executed with defined agendas and deliverables, without failure, and with full participation of the people in their assigned roles. This business cycle would commence as soon as a triage of the Change Request queue of work could be completed. Customer feedback loops were defined for each stage of the process. Triage was a critical first step and is discussed further in this article. The plan for this business cycle was presented to the CIO. She approved the plan for this business cycle, committed her management team to its principles, and successfully sold the plan to her peers in the company.
Problem #4 – How Frequently Should We Release Change Packages?- SOLUTION
The debate on this was not difficult – once we had made the earlier decisions to include operations change requests and exclude the emergency software fixes. We settled on a 2-week release change cycle. Our internal customers were already seeing changes made (or attempted) weekly with mid-week exceptions and surprises, so this could have been viewed as a step back by IT. However, the IT managers saw many shortcomings with more rapid attempts at change and were far more confident that the company would be well-served on a 2-week cycle. Specifically, change requests would be bundled together into a Release Change Package for implementation on alternate Thursday evenings. Our fallback position, if the Release did not succeed on Thursday night, would be to switch to a Friday evening implementation.
Triage
At this stage, the CIO evaluated how quickly all this good foundation work could be put into operation. As Release Manager, I advocated for a process solution supported by an industrial-strength commercial application that could be leveraged toward portfolio management, with many people updating their component parts, and project-specific support and tracking. However, finding, funding, purchasing and implementing such a baseline tool would require an estimated 3-4 months under ideal conditions. The CIO opted to proceed with the alternative “low-tech” approach for her organization. The mandate was to “find a way” to implement the essential processes by using the lowest-budget approach. The mandate was daunting. The prior “Change Coordinator” person had worked from a Change Control log in Excel that had fallen into disuse. The root causes for that condition appeared to be that the information could never be kept current, plus it only covered some of the Change Requests. No one had previously been assigned the responsibility to actual know and communicate the status of “small” change requests – of which there were several hundred. The log also attempted to store a lot of interim dates on small changes, and it duplicated interim dates that Project Managers maintained in MSProject on regular projects. The SPOC role had not been defined. As far as we could tell, 285 Change Requests were “open” – meaning submitted by clients and not yet completed. That number fluctuated each week as new ones got added and some got finished, but no one was certain of the status of each item.
It seems appropriate to define the term triage (courtesy of dictionary.com) -noun
- the process of sorting victims, as of a battle or disaster, to determine medical priority in order to increase the number of survivors.
- the determination of priorities for action in an emergency.
The IT managers knew we couldn’t cope much longer with incorrect information about all the victims (Change Requests) that were littering our battlefield. As Release Manager, I asked them to devote the resources necessary to obtain a current, accurate view of the following for each Change Request:
1. Change Request Number
2. Customer Name
3. Change Request Label (very short description)
4. First Requested Date
5. Status (Open, Completed, Being Worked, Cancelled, or Duplicate) (if completed, wanted a completion date)
6. Target Release Date (Not Available was OK)
7. SPOC Name
I was responsible for facilitating the triage process. This roughly consisted of some very long all-manager meetings, publishing many versions of a new Release/Change Request log in Excel, assigning segments of the list to the most knowledgeable workers for update, and numerous interventions. The sorting process consisted of IT managers agreeing on an initial High, Medium or Low priority for an “early” Release Target per Change Request. Customer VPs were also polled on their priority settings for Change Requests. The process was declared “finished” in 3 weeks. We achieved a stable state of Change Request information in the log and were ready to begin Release Management processes and the business cycle for control. The saga of Agile IT Release Management continues with THE CORE SOLUTION.
(c) By David W. Larsen
Proven, Practical Tactics For Agile IT Release Management – (Part 1: A CASE STUDY)
OVERVIEW:
This article is the first in a series of five that will explain how an IT organization delivered a release management process that exceeded its management’s expectations and provided a foundation for continued success. The series includes:
1. How did we get here – THE CONTEXT
2. First solution steps – DEFINITIONS AND TRIAGE
3. Intake and Release Planning – THE CORE SOLUTION
4. Production Change Control – FINAL QUALITY CONTROL
5. Metrics and Insights – LESSONS LEARNED
SUMMARY:
Many Information Technology organizations flounder when they are tasked to understand, organize and implement numerous changes to the system and application software serving their clients and end customers over a period of several years. This article explains at a high level the very practical and common sense framework and processes that successfully conquered the problem for one corporation and its IT team. How successful was this framework? Frankly, IT metrics is a dangerous and obscure element to discuss scientifically. But this organization accomplished the following:
- In one year, it increased its client satisfaction ranking from 2.5 to 4.0 on a 5 point scale.
- In one year, it delivered 85% more change requests and projects into production than in the prior 12 months.
- The organization exceeded its own stretch targets for throughput and change request cycle time by 40%.
- It accomplished these results with no headcount increases and no expenditures for IT “toolware”.
- It did increase the IT expense budget by 3.2% to cover the cost of a single consultant to instantiate the framework and processes for agile release management.
What was the secret sauce to make these accomplishments possible? The answer requires that we carefully consider the context for this organization.
CONTEXT:
The company and its IT department can be characterized as follows:
Company
- Industry – telecommunications – one segment of a very large Regional Bell Operating Company
- Primary Products – voicemail service and ancillary features
- Consumer base – 4 million consumer accounts with 25% growth forecast
- Total company headcount – about 500 people
- Primary operation – a 24X7 call center of 300+ people selling and servicing consumers on voicemail products and features
- Financial Results – High Line-of-Business Profit Margins within very large corporate structure
- Everyone worked in the same building
IT Organization
- IT staff – about 60 – most with 2-10 years of organizational history
- Functionally aligned into – Operations, Project Management and Analysis, System Development, QA and Help Desk, Configuration Management
- Applications – 7 major home-grown subsystems serving the company’s direct operations
- HR/Financial/Corporate functions were served by corporate parent and processes, with interfaces
- Technology – fairly current languages, operating systems and technical infrastructure (hardware, network, DBMS)
- Recently installed improvements:
- Software Configuration management tools, staff and processes
- Perceived primary problem – no effective control of changes submitted to production
- Everyone worked on the same floor
Strengths
- Strong and growing revenues
- Company Management – generally very experienced in call center management and product improvement processes
- IT Management – 80% had 4+ years within this organization and very little churn, only 2 levels of IT management
- Mature and successful IT processes included:
- Project Management
- Quality Assurance Testing
- Several strong IT manager advocates for improved Release Management
- Co-location of IT and its direct clients – the managers of the business functions
Weaknesses
- Company managers negotiated private deals to get their change requests and projects installed “earlier”
- No central clearinghouse for adjudicating departmental requests for IT changes
- No tracking system to account for all change requests and projects demanded and delivered
- About 325 requests/projects believed to be in play
- A haphazard intake and control/tracking process for “small” change requests
- Programmers could independently implement an application change to production
- No single point of contact/communications between the IT organization for each small change request
- Current status and target implementation date of any single change request difficult to obtain/pin down
- IT operations changes were totally independent of organizational change control and viewed as disruptive
Opportunities
- A new chance to consolidate and share information on everything on IT’s plate in a single place
- A chance to leverage the existing knowledge and maturity of the IT staff
- A chance to reduce the start/stop nature of IT work due to competing and vociferous input from company managers
- A chance to incorporate IT infrastructure changes from Operations in a planned manner
Threats
- Software developers desired new toolware – not more management processes
- Company business managers enjoyed calling the shots directly with programming resources
- Tension between IT managers on what were the best paths for organizational improvement
- IT had failed on its first attempt the prior year at Change Control and Release Management processes
- Consultants rarely added value
CONCLUSION / TRANSITION
The CIO, facing this situation, agreed to allow the Manager for Project Management and Analysis to contract for a resource to implement Release Management (Version 2). The CIO believed that she could deliver better results to her constituency by implementing change in a series of well-understood application package upgrades at regular intervals. She also wanted to take back to her peers a plan that they could understand and use to directly influence the order of implementation for their changes. The Manager of PM retained me as the Release Manager with the mandate to institute the processes and controls needed, and engaging all IT staff and VPs in business departments as needed for success.
The rest, they say, is “agile” history. To learn what it really takes, our story continues next with DEFINITIONS AND TRIAGE.
(c) By David W. Larsen
KANBAN helps Agile Adoptance
KANBAN supports a team’s journey of process improvement and helps expose the best solution. Kanban says,
…start with what you do now, modify it slightly to implement work pull and provide a transparent mechanism for self-organization, then evolve from there by recognizing bottlenecks, waste and variability that affect performance. As a result, every Kanban implementation will be different.
If you are working non-software development projects (ie IT projects) or Software projects, then KANBAN is an agile approach to seriously checkout.
If you want to understand WHY KANBAN? And how it can impact any company…..INFOQ has a video – from Agile 2009 conference – that explores how Kanban teams at a company matured through the lens of the Dreyfus Model for Skill Acquisition:
1 – Beginner
2 – Advanced Beginner
3 – Competence
4 – Proficient
“SKILL is not acquiring more knowlege of principles….it is changing the way you think or approach of problems by implementing new practices.”
TOPICS INCLUDE:
- Examination of how Agile was’t truly encouraged to be adopted in his company until Kanban was introduced
- Discuss a counter-intuitive technique for higher success and adoption rates of new methodologies
- Review common pitfalls teams encountered adopting Kanban and how it catepulted them into Agility
Click here to view Video at INFOQ
.
2010 Trends in Project Management
2010 brings with it multiple trends for Project Management. It is not surprising that many of these trends will help mature the world of project management as we know it today. Just as businesses must be flexible with market conditions – Project Management professionals and organizations must also adapt accordingly.
In talking to industry leaders in Project Management – several trends stand out.
Economic conditions have changed – Companies are changing – and project managers must understand these changes to be the leaders needed in 2010.
Trend 1 – Enterprises continue to look for Efficiencies in Process & Technology
Agile Project Managers Earn More Money !
Version One, an industry leader in Agile tools, teamed up with ASPE-SDLC and released its “first annual Agile Salary survey” today [PDF download]. The survey had almost 3000 respondents from 89 countries, and reveals some interesting findings – such as:
.
“Salary Trends are looking very positive for Agile professionals”
.
All size companies are using Agile – from 10 to 10,000+ employees.
Read more
The Business Driven Software Development webinar series
Business Agility enables an organization to respond quickly to external forces (such as new market opportunities and competitive forces) as well as to respond quickly to new insights attained internally.
While many organizations have achieved the local optimizations of more effective teams, few have achieved agility at the organizational level. Even when team agility has been achieved, if improvements to how the business is selecting their product enhancements isn’t done, overall return on investment of software development may not have significantly improved.
This series is organized around “roles” - Executives to Team Leads – so each person in an organization can be introduced to what “they” need to know to achieve business agility.
FREE Webinar Series – 7 sessions:
- Session 1 – An Overview
- Session 2 - Product Portfolio Management
- Session 3 – Where to Start Your Agile Transition
- Session 4 – Team Agility: Scrum or Kanban?
- Session 5 - Essential Skills for the Agile Developer
- Session 6 – Acceptance Test-Driven Development: Bring the Customer, Developers and Testers Together to Understand Requirements Up-Front
- Session 7 - The Role of Management in Lean-Agile Transformations
….SCROLL DOWN TO Reserve your seat for each session….
Read more
WEBINAR – Applying Lean Thinking to IT Projects
Scroll down to Listen to Webinar Recording…
In today’s business climate, ”more-for -less” is becoming very important. Applying “Lean Thinking” promises to deliver business results by greatly increasing quality, throughput, and productivity for organizations. An understanding of “lean concepts” can be used by Project Managers to improve process and enable IT organizations to more efficiently and effectively meet customer needs. This webinar with Carson Holmes will discuss lean practices that Project Managers can begin applying to IT Projects right away.
Let’s Connect!
