Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Another review of "Distributed Agile Teams" from Projects@Work
| LIke other bloggers here, I got a chance to download and read the excellent white paper titled "Distributed Agile Teams", which was based on an extensive survey and research done by Elizabeth Herrin on the Projects At Work site. Its a timely report given the increased global nature of projects being launched by multinational companies around the world. Though Agile is a strong advocate of having co-located teams, the reality is that you will most likely have development and testing teams in part of the world, while the product design and development in another with you as project manager coordinating it all from yet another location.
The first third of the paper went over the eye-opening statistics that resulted from the survey, while the rest of the paper discussed the results and further evaluations. I really liked the break down of the perceived benefits of distributed Agile teams to the eight categories of:
This list is ordered by the ranking of benefits with the first, flexibility, being the highest. I’m not surprised at these results and that quality would be last.
In my experience with managing dispersed teams, quality and especially the validation of quality was always the hardest in both traditional and Agile project management, but especially in Agile. The most popular and project management centric of the Agile methods, namely Scrum, advocates using a rigorous form of empirical process control to visually validate and inspect the quality of the output during iterations that get reviewed at least daily by the team and customer to allow adaptations to the backlog of items a particular Sprint is supposed to deliver on.
This process of “inspect and adapt” is a continuous one requiring all members from Team, to Product Owner, and Customer to be involved with to facilitate the flexibility and agility that lies at the heart of Agile methods. I agree completely with the recommended tips of having a central repository of code, with tools that automate and streamline rather than impede and hinder, as well as ensuring you have a project manager or ScrumMaster who excels at managing co-located teams first before moving to a distributed team.
I highly recommend downloading and reading this white paper. In addition, there was the announcement of a Scrum survey on this site that I hope as many people as possible participate in so we can all see how Scrum is used by Gantthead members!
|
Posted on: April 25, 2012 06:22 AM
| Permalink |
Comments (2)
Ruby Programming for Agile Development
|
I have written previously about the Microsoft based Scrum tools such as the MS Project 2010 and Visual Studio 2010 Scrum add-ins. But there are also a plethora of open source alternatives that have been discussed on this site and one in particular I find interesting is Redmine. It is a traditional PPM tool with the ability to track multiple projects and issues, act as a document repository, use Gantt and time tracking, etc. There has also been fertile development for plug-ins and of course, plug-ins for Scrum. The tool is written with the Ruby programming language and built on top of the popular Ruby on Rails framework.
Ruby was conceived on February 24, 1993 by Yukihiro Matsumoto(Matz) who wished to create a new language that balanced functional programming with imperative programming. According to Matsumoto, he "wanted a scripting language that was more powerful than Perl, and more object-oriented than Python. That's why I decided to design my own language". private Coordinate center, float radius; public void setCenter(Coordinate center) { this.center = center; } public Coordinate getCenter() { return center; } public void setRadius(float radius) { this.radius = radius; } public Coordinate getRadius() { return radius; }
}
attr_accessor :center, :radius Some conclusions:
As ScrumMasters and Project Managers, we like to focus on the work that leads to the end deliverables as well as the team and their skills and cohesiveness to get that work done. But it is also important not to overlook the appropriate tools that can be made available to them and carefully picking ones that will increase their productivity as well as enhance quality, instead of tools that impede and frustrate them. In software development, higher levels productivity languages like Ruby should receive special consideration. |
Posted on: April 21, 2012 11:44 AM
| Permalink |
Comments (1)
Performance Appraisals for Scrum Teams
| Read this interesting article on Scrum Alliance about individual team performance appraisals in Scrum teams and how they are antithetical to the process and spirit of Scrum. As the author Nanda Vivek states: The fundamental point is that if a Scrum team member is not able to contribute, then this points to a team problem. The Scrum spirit means that everyone jumps in to help; ideally, all team members work together on all of the stories. Different skill levels or types contribute to the best of their abilities. To create metrics for individuals, besides being inaccurate, would probably cause competition and division within the team. Individuals should work as a unit, be tracked as a unit, and succeed or fail as a unit...
My conclusion is that tracking an individual's performance constitutes crime in the Scrum world. The fundamental idea of Scrum is team collaboration, and team members "volunteer" for tasks rather than having them assigned. One of the core values of Scrum is courage, and it's not a bad practice to announce at the daily stand-up, "I missed my task timeline today." If that's the case, the Scrum team collaboratively aligns itself to meet the sprint backlog, at least enough to result in a shippable product when the sprint ends. It's certainly possible that not all tasks in the sprint backlog get completed at the end of the sprint, but the Scrum team should be smart enough to plan the next sprint in a way that avoids a similar pitfall.
I think this notion rest on a flawed assumption that because Scrum teams are self-organizing, that the teams would by default, just "volunteer" for tasks on a backlog item. During the initial planning process, a review of the requirements, backlog items, story boards, etc. will allow the ScrumMaster and team leads to determine what resources and skillets need to be identified to complete the working deliverables at each iteration. This would be no different than in traditional project management where resources need to be identified, assigned and allocated for a project.
In addition and especially if you’re running Scrum in a large organization, these resources will be working on other projects that you must weigh against your own to get a realistic sense of when your project can be delivered based on the priority of your project weighed against others. The reality is that often times you have to "borrow" these resources to complete your project both in Scrum and traditional projects.
Furthermore, as well as self-organizing is the idea that teams would be cross-functional in Scrum wouldn't negate the need for a subject matter expert in Java development, QA tester, UI design, etc. to be identified. If an XP process is used so that you pair people of different skill sets to work with each other, these other SMEs should acquire enough skills to pick up the slack when the core team SME is not available or too busy to get their deliverables done on time. But this takes time to build this maturity and would still require you to identify, acquire and assign these resources to a Scrum project before you can get to the point where teams start to self volunteer and organize. If team members leave, this process starts over again.
In these situations, the Agile retrospective becomes important to evaluate a team’s performance as well as understanding an individual team member's contribution to both the velocity and completeness of their contribution to the deliverables of each iteration. This historical data is important to have to anticipate the success of upcoming Scrum projects. A company's financial stake is on the line for the success of the delivery of Scrum projects and whether we like to acknowledge it or not, individuals in a team are paid to deliver on these projects and the only way to accurately and fairly gauge this is by analyzing in depth their performance and contribution to the project.
I think this notion rest on a flawed assumption that because Scrum teams are self-organizing, that the teams would by default, just "volunteer" for tasks on a backlog item. During the initial planning process, a review of the requirements, backlog items, story boards, etc. will allow the ScrumMaster and team leads to determine what resources and skill sets need to be identified to complete the working deliverables at each iteration. This would be no different than in traditional project management where resources need to be identified, assigned and allocated for a project.
In addition and especially if you’re running Scrum in a large organization, these resources will be working on other projects that you must weigh against your own to get a realistic sense of when your project can be delivered based on the priority of your project weighed against others. The reality is that often times you have to "borrow" these resources to complete your project both in Scrum and traditional projects.
Furthermore, as well as self-organizing is the idea that teams would be cross-functional in Scrum wouldn't negate the need for a subject matter expert in Java development, QA tester, UI design, etc. to be identified. If an XP process is used so that you pair people of different skill sets to work with each other, these other SMEs should acquire enough skills to pick up the slack when the core team SME is not available or too busy to get their deliverables done on time. But this takes time to build this maturity and would still require you to identify, acquire and assign these resources to a Scrum project before you can get to the point where teams start to self volunteer and organize. If team members leave, this process starts over again.
In these situations, the Agile retrospective becomes important to evaluate a team’s performance as well as understanding an individual team member's contribution to both the velocity and completeness of their contribution to the deliverables of each iteration. This historical data is important to have to anticipate the success of upcoming Scrum projects. A company's financial stake is on the line for the success of the delivery of Scrum projects and whether we like to acknowledge it or not, individuals in a team are paid to deliver on these projects and the only way to accurately and fairly gauge this is by analyzing in depth their performance and contribution to the project.
Individual performance appraisals are not antithetical to the Scrum process and is actually quite important to the continued success of future Scrum projects. Like any project management assessment, it needs to be done with a clear goal in mind and done up front and transparently with the teams.
|
Posted on: April 09, 2012 06:46 PM
| Permalink |
Comments (1)
HBR on Lean, Agile and IT Process Improvement
| Just read a Harvard Business Review blog which advocates leveraging your IT department for overall business process improvement. The author, Brad Power, cites how financial giants Nationwide and ING were able to take practices such as Lean and Agile used in their IT process improvements, to achieve more effective and efficient delivery of IT value for their organizations, to deploying it throughout the rest of the organization:
Building on their team successes, they created an "Agility capture team" of senior IT leaders to address larger issues. They have weekly planning meetings and conference calls twice a week to work on internal customer service improvements. While the IT organization is driving this, more importantly they have roped in business unit and functional heads to surface their needs. As a result, process improvement activities have begun rippling out from the IT project team level to the core operations of the business...
Building a new mindset of making many smaller changes and learning from each one, instead of getting a detailed specification and delivering it, has been a concerted cultural transformation. This continuous improvement thinking is well known in manufacturing, but few do it well or consistently...
Improving the performance of the IT department is hard enough. But by adopting the techniques of process improvement leaders, Nationwide and ING are doing what's nearly impossible at most large organizations: forming cross-functional teams to quickly design and implement better ways of serving customers and improving enterprise performance.
While I agree in general with the author, some of the blog comments in my opinion hit it dead on about the general perception of IT within most organizations. Ironically, through innovation in the US is typically associated with high tech companies especially in an area like Silicon Valley where companies such as Google, Cisco, Facebook and other notables reside, when you look at the majority of IT departments that is tasked with managing high tech systems in the corporate world, they are typically seen as a "keep the lights on" type of department. An unavoidable cost center and expense.
With the world in a prolonged recession and IT departments dealing with slashed budgets and limited resources, it is often hard enough just to manage and maintain corporate legacy IT systems, let alone take part in and become a strategic business partner to streamline and improve overall business operations and management. But this where project management is vital, since all major initiatives to deploy new technologies and/or to enhance and optimize existing technologies are done through projects. Especially projects that will help a company to deploy a new system that will enable it to become a market leader or capture untapped marketshare will have lots of visibility throughout all upper management ranks. So utilizing sound project and deployment practices such as Lean and Agile to get such projects done effciently and effectively will allow an IT department to demonstrate their ability to help the whole organization to achieve overall business efficiencies and continuous improvements. Since technology is now so ubiquitous throughout every business function and process in practically all companies around the world, the time is now to start seizing these kinds of opportunities. |
Posted on: March 17, 2012 04:35 PM
| Permalink |
Comments (1)
Agile Certification Adoption Metrics
| I saw this graphic on the Critical Path blog about the most recent number of PMI-ACP (Agile Certified Practitioner) certifications to be awarded in the month of January 2012:
The PMP is still the king of the hill at 4047 new PMPs, but the 2nd place finish of the ACP certification is pretty surprising given how new this is. As the blog states, "PMI-ACP reached a number in one month that took the other certification a few years". This got me thinking of the overall adoption of Agile/Scrum certifications and how to graph its progression. Thankfully, Google has a tool called "Google Insights for Search" that graphically shows the number of searches on their site for key terms. Typing in "Scrum Master Certification" revealed the following growth since 2004:
Since 2006, it has been an explosive growth! Typing "PMP Certification" revealed this graph:
Which shows a consisteny, yet slighly downward trend. When you combine the two, you see a surprising divergence:
I wouldn't read these as an authoritative graphical representations of the correlation of adoption between the two certifications or growing popularity of Agile/Scrum over PMI/PMBOK/PMP or visa versa, but it is interesting nevertheless. If anyone out there knows of or has a more rigorous research comparison I'd like to know. In the meantime, try out and play with Google's search insight. |
Posted on: March 08, 2012 12:02 AM
| Permalink |
Comments (0)