Category

Agile Project Management

Cutting-edge Agile methodologies, software development techniques and project management practices.

Nov 032015
 
Considering Group Dynamics in Agile Adoption

Understanding individuals and how they interact with each other is one of the key priorities of Agile. In fact, the very first statement of the flagship Agile Manifesto highlights this priority. When individuals interact positively with each other, they promote the group’s common goal. This is collaboration. Honest collaboration invariably challenges the inherently territorial nature of humans. We love to hold on to our spaces and boundaries (both geographical and mental). Collaboration permeates those boundaries and makes them porous. The need to break down the territorial mindset in humans is perhaps the hardest thing to comprehend and accept in an Agile culture change. Promoting collaboration fundamentally depends on understanding how two (or more) individuals interact Read more

Sep 302015
 
Strategy And Backlogs Exist To Be Adjusted

During today’s webinar about ALM, I took great pains to talk about what constitutes a real strategy for software innovation, and what an imitation strategy looks like. Many of the questions we receive at Cutter, such as, “What scaled Agile approach should we pursue?” are impossible to answer without a strategy to guide these sorts of decisions. Before talking about scaled Agile, or whatever the topic du jour is, we first must backtrack into a discussion of the strategic imperatives behind these questions — assuming anyone knows what those imperatives are. One of the hardest aspects to understand about strategy, either for ALM or anything else, is that it’s not written on stone tablets. Strategy is made Read more

Aug 112015
 
DevOps Needs an Architectural Foundation for QA

I have spent most of my professional time in telecommunications company projects. Although both telecommunications and IT are technology-intensive industries, they differ in a fundamental way. Telecommunications services are end products and customers pay for them. IT services represent a means for supporting the products delivered to customers, and customers pay for the product, not for the IT component included in the product. This is the reason why a service assurance practice is much better developed and established in the telecommunications business. But the world is changing, and IT-based services are increasingly becoming end products themselves. Practices for IT-based service assurance can gain a lot if we pattern them on telecommunications practices. The latest developments Read more

Serious Games At Agile 2015

 Posted by on Aug 10, 2015  No Responses »
Aug 102015
 

Every year, serious games have made a larger appearance at the Agile Alliance’s yearly conference. For instance, a few years ago, one session featured a game that simulated the collaboration between UX professionals and an Agile team. Other sessions demonstrated how to use serious games to improve the dialogue between Agile teams and their customers. If you know me, you’re already aware that I have a special interest in this topic, in part because, as it says in my LinkedIn profile, one of my professional missions is to make serious games wildly successful, not just in software development, but in lots of settings that desperately need the typical rules of conduct disrupted. This year was Read more

Aug 062015
 

One of the best presentations I heard this week at Agile 2015 was Declan Whelan and Jason Little’s pithy summation of the necessity of structural change in organizations embracing Agile. Their argument was as pithy and forceful as the phrase, No justice, no peace: No structural change, no Agile. If you want to judge whether any organization, including the big and complex ones most notoriously prone to inertia and rigidity, has embraced Agile, look no further than the presence or absence of significant structural change. Agile should remold the organization, starting with the team, not just turn into another set of governance rules (“Thou shalt do a daily stand-up”) imposed on teams. We’ve been over Read more

Jul 302015
 

Software innovation has reached a level of necessary sophistication where purely technical skills are necessary, but not sufficient. “Computer science” now significantly overlaps social science, incorporating the insights and methods of psychology, sociology, economics, and anthropology. This evolution of the profession has profound implications for skills, roles, organizational structures, product and project decisions, innovation timelines, and a whole host of other considerations that go to the heart of how software professionals work. This topic is far too large to encompass in a single blog post, so I will address it across several. Eventually, we will identify the reasons behind the merging of computer and social science, and look ahead at the implications for organizations who Read more

Jul 162015
 

If you’ve been following my series of posts about ALM, you know that the Lean concept of flow is one of ALM’s two central pillars. (The other is alignment, an indicator of the likelihood that the software organization is delivering value.) Whenever I talk about anything related to Lean, I’m always a little nervous. People misinterpret Lean frequently, with highly destructive consequences, so putting a Lean frame around ALM is almost asking for trouble. The most frequent distortion of Lean that I’ve seen in software development is the following syllogism: Lean tells us that we should reduce waste. Unused capacity is a form of waste. Therefore, we should maximize the utilization of our capacity. To Read more

Jul 052015
 

[For some related posts about application lifecycle management, click here and here. For my video series on ALM, click here.] Software teams are usually very responsive either to their own organization or the customer; it’s harder to find a team that is good at responding to cues from both. For example, I’ve known teams within corporate IT that are so enmeshed with their customer that the business, for all practical purposes, manages and runs them. I’ve also seen teams in software companies that are primed to respond every time an executive clears her throat, but far less responsive to customer issues. In part, these behaviors are the result of corporate culture: for example, in vertically-oriented Read more

Jun 302015
 
Requirements Are An ALM Problem 100% Of The Time

Say that you had a recurring problem with your car. Every time you stalled, the radio was playing. While there might be other contributing factors, such as running the air conditioning, or recharging your phone through the car, you’d be inclined to think that the radio is a major contributing factor. The capacity of the car’s electrical system might be the ultimate culprit, but you’d also be suspicious that the radio is drawing far too much power, all by itself. In 100% of the application lifecycle management (ALM) assessments that I’ve done for clients, requirements are one of the major contributing factors to ALM problems. (If you want to know the assumptions that go into Read more

Jun 162015
 
Agile Development Requires Agile Staffing

The impacts of the growing agility requirements within staffing cross a broad territory, currently limited only by the relatively small number of individuals involved. However, these impacts will continue and likely grow in importance as Agile principles become prevalent. Some potential issues and needs to look out for include: Revising existing job descriptions and establishing new specialties. Businesses should create new Agile jobs, such as product owner and ScrumMaster. These are not management jobs in the traditional sense, but they do require resources and responsibilities. Older project management positions should be altered or eliminated. Similarly, Agile development team members should develop collaboration and communications skills and may need training in the use of collaborative technologies, particularly Read more