Scrum for Venture Capital Companies
|
According to the article, adopting Scrum throughout their business processes allowed the group to double their productivity, while working fewer hours. Scrum is used as a best practice framework for their project consulting services, sales, marketing, finance and customer support for their portfolio of companies. As illustrated in the Maxwell Curve, coined by Scott Maxwell who is a principal founder, assuming a team member can take on approximately 20 perfect hours a sprint, the starting velocity for a full work week starts at 80, with the equivalent focus factor of 50% utilization for a 40 hour work week. Unplanned stories are tracked seprately. Due to this, the team at OpenView realized that using perfect hours instead of story points implied that the measured velocity can only increase if:
Additionally, continuous improvements and impediment removal can decrease the amount of time spent on individual stories by shrinking the story size while simultaneously increasing the output of work with no increase in the Sprint's velocity. As time goes on and more iterations are completed, productivity increases which creates a culture of working less hours and no weekends. For venture capital firms, investors will typically drive startup companies to work harder and longer to get a quicker ROI on their investments which leads most companies to work well beyond the 40 hour work week. Scott found that due to Scrum's intensity, the peak of production waned after 50 hours, so he insisted the teams to work at a sustainable pace and avoid night and weekend work. But from his analysis, he did expect that the production of work would double. According to the article, this focus on higher velocity in perfect hours with less actual hours worked, compelled the teams to remove obstacles, overhead and communication gaps and to increase story clarity so as to increase the number of perfect hours completed. This allowed them to acheive double productivity of work while working less hours. This is not to say that they did not experience challenges. Some of the most notable where:
Though I can't verify the truth of their claims to Scrum's productivity increases, I have witnessed similar increases in Scrum projects (or projects using Scrum/Agile-like techniques) I've lead or been involved with and this was when I had the kind of organizational and upper management support that OpenView had articulated in the article. It is interesting to see that Scrum is being adopted outside software development and getting the kinds of productivity gains it is famous for. |
As I mentioned in a previous 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.
|
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.
|
No doubt social media and all its technological manifestations is all the rage right now. This "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.
|
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. |
