No doubt social media and all its technological manifestations is all the rage right now. This "
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Agile Integrated Change Control
| Change happens and is a fact of life for anyone involved in a project. How a project manager deals with changes throughout a project determines whether a project succeeds or fails and this needs to be integrated throughout the lifecycle of the project. According to the PMBOK 4th edition, integrated change control "is the process of reviewing all change requests, approving changes and managing changes to the deliverables, organizational process assets, project documents and the project management plan."
For the project manager who has to work within a traditional process driven environment and/or desires to incorporate Agile practices to align with the PMBOK driven one, must keep in mind that integrated change control is not much different in Agile and the PMBOK. Agile at heart is always driven by the desire to run the minimalist process that achieves the most value, thus the change control process must be streamlined and integrated into the daily routine of team members, e.g., the daily stand-up meeting. Process changes must be owned by the team, whereas product changes are owned by customer represented by the Product Owner as is typically done in Scrum.
These changes are documented in the ordered product backlog. During release and iteration planning, these higher ordered items move from the backlog to actually being coded, tested and accepted by the customer at the end each iteration. The customer feedback at the end this iteration become the integrated change process that enable the team to make the necessary adjustments. The product backlog may get re-ordered and re-shuffled for the next iteration. Seen in this light, all members involved with the project become the equivalent of a change control board (CCB) outlined in the PMBOK.
One major change in this practice is how the Agile PM acts more as a "go-between" with the customer and the team. In a traditional PMBOK driven process, the PM would be responsible for driving and managing the changes in the project management plan, whereas in an Agile driven one, he/she acts more as a facilitator for the customer and team to reach a collaborative decision regarding changes to the product backlog items. The process of re-ordering and re-shuffling items in the product backlog with customers and team, make it easier for all concerned to see the tradeoffs involved when something that needs to get added causing something else to get dropped. For very malleable products like software, it would be more flexible to use this then a rigid change control list.
|
Posted on: November 29, 2011 11:50 PM
| Permalink |
Comments (1)
Resource Management With Social Media Technology?
|
The posting claims Hello's most important design feature:
Is that an employee's profile is the centerpiece of the platform. In other words, all employee activity — blogs written, community and forum participation, bookmarks posted, wiki input, tags created, etc. — are all tightly linked back to an employee's profile. Therefore, the profile represents an aggregated, real-time view of the employee. For example, if a consultant is reading another consultant's blog, by clicking on the blogger's name, the reader could see all the expertise areas, interests, documents, and activities for that blogger.
An employee's profile shows professional projects and work interests (e.g., bio, resume, documents, and major clients) as well as personal hobbies, interests (e.g., personal tags), and associations. The graphic of an employee's availability is listed within all this information, thus creating a data-rich context for colleagues to think about not only availability, but also fit.
A couple of major issues come to mind for me. One of them is privacy or lack thereof. Of course if you are working for a company you do not own the computer, network and software systems that they provide for you, so by default you do not have a right to the privacy of the data and use of their systems. On the other hand, many of the social media activities that you would engage in are very much the kind of activities that most organizations these days would consider personal use rather than business use. How would an organization know if an employees is perusing a legitimate colleague's Facebook page or getting dirt on a old high school acquaintance? And as an employee, do you want your organization to monitor and aggregate all your social media activities both professional and personal?
The other issue is the hype bandwagon. I'd say we are close to the peak of the techology hype cycle for social media. This mirrors the same phenomenon that occured within the narrower niche of PPM systems. These large web based systems were touted a while back ago as the answer to all project, portfolio and resource management problems for organizations and within the hype cycle, many have now gotten over the "trough of disillusionment" with these systems. No doubt that modern technology based tools are a valuable asset, but the focus has to be on the people and the process first.
This is not to say that incorporating social media to make project and resource management more effective is not worth looking into. I've found using a twitter like feed on a project intranet website a useful way to document minor changes, issues and status on projects, especially ones where rapid development and turnaround is expected. This can compliment daily Scrum meetings quite well if used effectively.
In any event, its interesting to see how one organization is utilizing social media for their project and resource management needs.
|
Posted on: November 16, 2011 12:50 AM
| Permalink |
Comments (3)
Organizational Patterns: A catalyst for change in an Agile environment
| In the software engineering field, especially with regard to object oriented design and programming, there has been a drive within the past decade and a half to identify recurring patterns in OO design and code that will enable more re-usability and “abstractions”, which are very general descriptions or templates for how to solve a problem that can be used in multiple situations.
These patterns are not finished designs or software components that can be plugged into or generated into actual code, but rather they are guidelines and best practices that display how the relationships between classes or objects interconnect and interact without actually specifying how to do so in some programming language. This is left for the implementer to decide on. This was famously published in “Design Patterns: Elements of Reusable Object-Oriented Software” (1994) which outlined 23 classic design patterns and is still referred to and read to this day.
This same principle has been applied to organizational design and specifically, how Agile software development projects can be seen and understood within the notion of recurring patterns that describe the “recurring structures of relationship, usually in a professional organization, that help the organization achieve its goals” [http://en.wikipedia.org/wiki/Organizational_patterns]. Utilization of these patterns can be an important inducer and catalyst for change management in an Agile environment.
A book by James O. Coplien and Neil B. Harrison, titled “Organizational Patterns of Agile Software Development” is one of the only reference books that attempts to apply organizational patterns within the context of Agile software development projects to identify more effective and re-usable solutions that can be used by a project manager in any solution that is worth a definite read.
The book is written with an academic style and is based on rigorous research results that comes from a well-executed research projects by the authors and others. Part I, consisting of chapters 1-3, give an overview of patterns, explain how they were discovered, how the data was obtained, and how you might use the book. I recommend you read this section even if you are familiar with patterns or at least skim it.
The heart of the book is in Part II. This section presents the patterns, organized in two major categories -- organization design and organization construction. There are about one hundred or so patterns in these sections that address most of the situations that organizations of almost any size will encounter as they try to improve their software development process. Some of the patterns are ones that should be very familiar, but are now named in the book. By describing them at a high level of abstraction, we are provided more semantic context per word then if we were to explain them individually, which is the purpose of patterns in the first place.
Some patterns are common sense such as "Get On With It": You know what you need -- at least enough to get started -- so, as soon as you have enough information and some confidence, start developing areas that you have confidence in. Others such as “Developer Controls Process” recognizes the centrality of the developer in the development of a feature and urges you to make the developer the focal point of process information. Approaches like this might seem contrary to he way you manage projects, but by having a pattern outlined, it provides you a starting point to define your own patterns.
There are two more parts. Part III discusses organizational principles, with advice on how to prepare your organization for change. These are patterns in a different form, but they are an important cog in the machinery of organizational change. Part IV provides case studies that illustrate the application of the principles of Part III and the patterns of Part II.
This notion of patterns was highly influenced by the architect and theorist Christopher Alexander in his book “A Pattern Language: Towns, Buildings, Construction” (1977), which illustrate how patterns describe a problem and then offer a solution by establishing a set of problems and documented solutions. This provides a mechanism and metaphor for anyone in a community to improve their towns and cities to effect change and build a better living environment. Therefore, organizational patterns can be organized into pattern languages: collections of patterns that build on each other providing general descriptions or templates for how to solve a problem that can be used in multiple situations. Coplien and Harrison’s book provides the project manager an excellent starting point for identifying, building upon and utilizing patterns to act as a catalyst for change in an Agile environment.
This notion of patterns was highly influenced by the architect and theorist Christopher Alexander in his book “A Pattern Language: Towns, Buildings, Construction” (1977), which illustrate how patterns describe a problem and then offer a solution by establishing a set of problems and documented solutions. This provides a mechanism and metaphor for anyone in a community to improve their towns and cities to effect change and build a better living environment. Therefore, organizational patterns can be organized into pattern languages: collections of patterns that build on each other providing general descriptions or templates for how to solve a problem that can be used in multiple situations. Coplien and Harrison’s book provides the project manager an excellent starting point for identifying, building upon and utilizing patterns to act as a catalyst for change in an Agile environment.In the software engineering field, especially with regard to object oriented design and programming, there has been a drive within the past decade and a half to identify recurring patterns in OO design and code that will enable more re-usability and “abstractions”, which are very general descriptions or templates for how to solve a problem that can be used in multiple situations.
These patterns are not finished designs or software components that can be plugged into or generated into actual code, but rather they are guidelines and best practices that display how the relationships between classes or objects interconnect and interact without actually specifying how to do so in some programming language. This is left for the implementer to decide on. This was famously published in “Design Patterns: Elements of Reusable Object-Oriented Software” (1994) which outlined 23 classic design patterns and is still referred to and read to this day.
This same principle has been applied to organizational design and specifically, how Agile software development projects can be seen and understood within the notion of recurring patterns that describe the “recurring structures of relationship, usually in a professional organization, that help the organization achieve its goals” [http://en.wikipedia.org/wiki/Organizational_patterns]. Utilization of these patterns can be an important inducer and catalyst for change management in an Agile environment.
A book by James O. Coplien and Neil B. Harrison, titled “Organizational Patterns of Agile Software Development” is one of the only reference books that attempts to apply organizational patterns within the context of Agile software development projects to identify more effective and re-usable solutions that can be used by a project manager in any solution that is worth a definite read.
The book is written with an academic style and is based on rigorous research results that comes from a well-executed research projects by the authors and others. Part I, consisting of chapters 1-3, give an overview of patterns, explain how they were discovered, how the data was obtained, and how you might use the book. I recommend you read this section even if you are familiar with patterns or at least skim it.
The heart of the book is in Part II. This section presents the patterns, organized in two major categories -- organization design and organization construction. There are about one hundred or so patterns in these sections that address most of the situations that organizations of almost any size will encounter as they try to improve their software development process. Some of the patterns are ones that should be very familiar, but are now named in the book. By describing them at a high level of abstraction, we are provided more semantic context per word then if we were to explain them individually, which is the purpose of patterns in the first place.
Some patterns are common sense such as "Get On With It": You know what you need -- at least enough to get started -- so, as soon as you have enough information and some confidence, start developing areas that you have confidence in. Others such as “Developer Controls Process” recognizes the centrality of the developer in the development of a feature and urges you to make the developer the focal point of process information. Approaches like this might seem contrary to he way you manage projects, but by having a pattern outlined, it provides you a starting point to define your own patterns.
There are two more parts. Part III discusses organizational principles, with advice on how to prepare your organization for change. These are patterns in a different form, but they are an important cog in the machinery of organizational change. Part IV provides case studies that illustrate the application of the principles of Part III and the patterns of Part II.
This notion of patterns was highly influenced by the architect and theorist Christopher Alexander in his book “A Pattern Language: Towns, Buildings, Construction” (1977), which illustrate how patterns describe a problem and then offer a solution by establishing a set of problems and documented solutions. This provides a mechanism and metaphor for anyone in a community to improve their towns and cities to effect change and build a better living environment. Therefore, organizational patterns can be organized into pattern languages: collections of patterns that build on each other providing general descriptions or templates for how to solve a problem that can be used in multiple situations. Coplien and Harrison’s book provides the project manager an excellent starting point for identifying, building upon and utilizing patterns to act as a catalyst for change in an Agile environment.
|
Posted on: November 09, 2011 10:05 AM
| Permalink |
Comments (1)
When Even Agile Is Considered Overhead
| This article by Mike Cohn on the Scrum Alliance site, discusses the perception that some people have that Scrum can be a "burden". This is an often heard complaint I've experienced throughout my PM career whether it pertained to Agile or traditional methods. Implicit in this argument is the notion of project management in whatever form, method or process as being "overhead" for getting things done. Now that the profession has matured quite a bit and is established in many industries and organizations, you will hear less of this than in the past, but the perception still holds for some people. Even in one of the most lightweight PM methods around, namely Scrum, the perception will hold as Cohn states, "these comments have surprised me—Scrum requires only a single fifteen-minute meeting each day plus a half- to full-day at the start and finish of a sprint. That doesn't seem like much overhead." While I can agree with this, I can still see why the perception holds and it typically has to do with several core factors. First, it has to do with the maturity level, or lack thereof in a particular organization. Scrum and Agile has their roots in software companies, and especially for software start-up companies where the core application or system was developed on the fly by founders loaded up on sugar and caffeine laden sodas and pizzas and all night coding sessions are the norm, even adding a routine of daily meetings and short planned Sprints can seem like overhead. But at some point, they will need to hire developers and ship a useable product and this is where some planning and process needs to be in place. Even for more mature or established organizations, there could be a lack of established planning, development and deployment practices where introducing project managment practices can be perceived as overhead. Directly related to the above is upper managements lack of support for project managment. And I'm not talking about where an organization experiences chronic delays and overbudget projects and decides to make project management a directive for the organization or department. As Cohn states, " there's a natural tendency to bristle at any direction given from above. Calling the few generative rules of Scrum 'too much overhead' may be a team's way of expressing displeasure at having any decision pushed down onto them from above." What I'm talking about is where upper management needs to view project management as a strategic objective of the organization and takes the time to carefully plan, advocate and carry through with implementing project management practices that match their orgainizational's needs and strategic objectives. Finally, if the project manager or ScrumMaster is not adequately doing his or her job of tracking and managing project details, removing impediments, communication, etc., then their role and the project management role in their organization in general, will be seen as overhead. But if the project manager or ScrumMaster does an outstanding job, there is no better way in my opinion to sell project management to an organization than when a project manager or ScrumMaster proves this in the flesh. Though you cannot always control factors such as the maturity of your company or upper management's decisions, you can control how you manage your projects and the manner in which you do so can have dramatic impacts to whether it is perceived as overhead or strategic necessity. |
Posted on: October 30, 2011 11:23 PM
| Permalink |
Comments (1)
Using Scrum in a Flat Global World
| With this month’s Gantthead emphasis on global project management, it’s fitting to discuss using Scrum in an increasingly flat, global work environment. With the trend staring in manufacturing in the 80’s and 90’s, coupled with the rapid advances in communication technologies, the imperative to to deliver application development in shorter timeframes, with better quality, lower cost and with globally dispersed teams is now the “new” normal.
But how do we fit this Agile method which expects co-located, cross functional teams that iterate through sprints in a self-organizing fashion, with a capable ScrumMaster removing impediments and prioritizing backlog items from a Product Owner nearby, to one where teams, customers and Product Owners are located in another part of the globe, in multiple time zones and don’t all speak the same language fluently?
Not very easily and not without some significant tweaks to Scrum.
First of all, though Scrum and Agile purist will scoff at overly formal and complex processes, you will have no choice but to establish and agree upon some structure and process to how you will arrange daily stand-up meetings (or calls and emails), prioritize backlog items, run and review Sprints and the working deliverables each Sprint must create, as well as an escalation procedure to remove impediments. This escalation procedure is important since the time zone difference between a team and a ScrumMaster could be significant. For example, a team located in Asian could experience a significant impediment that will not be known to a ScrumMaster in the US till the next day. The ScrumMaster removes the impediment, but will not find out if it was effective till the next day, and worse, if the impediment was not successfully removed, it will add another couple days of cycling through till it gets resolved. This is not very agile!
A ScrumMaster will have no choice but to pre-define a clear communication, escalation and implementation plan that allows flexibility, yet enough structure and guidance to ensure deliverables get done on time. It will also be very important to truly have a self-organizing team. If you can’t be in the same presence and time zone of your team, you will really have to rely on them to be self-organizing, efficient and effective. This means you have to carefully select a good team or work with one that you can trust.
You will also need a clear articulation of what it means to be “done”. Use good software tools that will allow you to implement continuous integration of builds, source control and test driven development to ensure that the software being developed and delivered in each Sprint has been through the necessary QA before being released to the customer so that done is “done”!
This is hard and expect to lose sleep, but if you can balance both having a clear and well thought through coordination procedure and process, while still allowing the flexibility and agility that Scrum is known for, you may just get the successful results typical of Scrum when done right, but on a global scale.
This is hard and expect to lose sleep, but if you can balance both having a clear and well thought through coordination procedure and process, while still allowing the flexibility and agility that Scrum is known for, you may just get the successful results typical of Scrum when done right, but on a global scale.With this month’s Gantthead emphasis on global project management, it’s fitting to discuss using Scrum in an increasingly flat, global work environment. With the trend staring in manufacturing in the 80’s and 90’s, coupled with the rapid advances in communication technologies, the imperative to to deliver application development in shorter timeframes, with better quality, lower cost and with globally dispersed teams is now the “new” normal.
But how do we fit this Agile method which expects co-located, cross functional teams that iterate through sprints in a self-organizing fashion, with a capable ScrumMaster removing impediments and prioritizing backlog items from a Product Owner nearby, to one where teams, customers and Product Owners are located in another part of the globe, in multiple time zones and don’t all speak the same language fluently?
Not very easily and not without some significant tweaks to Scrum.
First of all, though Scrum and Agile purist will scoff at overly formal and complex processes, you will have no choice but to establish and agree upon some structure and process to how you will arrange daily stand-up meetings (or calls and emails), prioritize backlog items, run and review Sprints and the working deliverables each Sprint must create, as well as an escalation procedure to remove impediments. This escalation procedure is important since the time zone difference between a team and a ScrumMaster could be significant. For example, a team located in Asian could experience a significant impediment that will not be known to a ScrumMaster in the US till the next day. The ScrumMaster removes the impediment, but will not find out if it was effective till the next day, and worse, if the impediment was not successfully removed, it will add another couple days of cycling through till it gets resolved. This is not very agile!
A ScrumMaster will have no choice but to pre-define a clear communication, escalation and implementation plan that both allows flexibility, yet enough structure and guidance to ensure deliverables get done on time. It will also be very important to truly have a self-organizing team. If you can’t be in the same presence and time zone of your team, you will really have to rely on them to be self-organizing, efficient and effective. This means you have to carefully select a good team or work with one that you can trust.
You will also need a clear articulation of what it means to be “done”. Use good software tools that will allow you to implement continuous integration of builds, source control and test driven development to ensure that the software being developed and delivered in each Sprint has been through the necessary QA before being released to the customer so that done is “done”!
This is hard and expect to lose sleep, but if you can balance both having a clear and well thought through coordination procedure and process, while still allowing the flexibility and agility that Scrum is known for, you may just get the successful results typical of Scrum when done right, but on a global scale.
|
Posted on: October 25, 2011 08:13 PM
| Permalink |
Comments (1)