The Latest
Believe the Territory[magazine] Test plans are seldom followed as written, project plans hardly ever fit the actual progress, and process models are rarely followed to the letter. Markus Gaertner examines why most of our documents become obsolete and gives advice about whether or not to continue to write and maintain them. |
||
A Common Language[magazine] Do your stakeholders use different terms to talk about the same concept or use the same term but in a different way? A domain model can clarify key concepts and the relationships between them, helping your team resolve ambiguous terms and leading to more productive discussions about project requirements. |
||
Unintended Consequences[magazine] Every action elicits a response, but sometimes that response is not what we expect. These anecdotes from industry experts are good examples of how our best intentions don't always match our plans. |
||
The Weekend Testers[magazine] This is the true story of freedom from the monotonous work of checking. It is the story of what happened when a few passionate testers took responsibility for their own education and fun in testing. Explore how they test, learn, and contribute to the open source. |
||
Leveraging A Learning Culture[magazine] Mistakes happen. It's how you respond to them that matters. Teams might react to a bug with panic and blame, leading to a quickly hacked fix and possibly more issues. Taking time to investigate and learn leverages problems into process and practice improvement and a higher quality product. |
||
The Marriage of Lean, Scrum and Extreme Programming (XP)[article] Many flavors of Agile have emerged: Scrum, Lean, Feature Driven Development (FDD), and Extreme Programming just to name a few. These methods have numerous complementary and distinguishing features, but the gamut of choices can be confusing and disorienting - as if being told to choose the best from 31 flavors of ice cream. Return on Investment (ROI) is important to me, so Lean must be the answer. But wait, I also want to be agile with my business priorities so I’ll choose Scrum. We are left wanting a simple question answered: “Which Agile method should I choose for my organization?” |
||
Insights From Three Agile/Lean Product Development Thought Leaders[article] Here is what Mark Lines (Unified Process Mentors, Co-Founder) has to say: The fact that basic agile concepts are so easy to learn, as well as the proliferation of certification courses with very little investment required has had both positive and negative effects. Certainly the mindshare of methods such as Scrum has exploded in our industry and people are excited about the benefits that agile can deliver in terms of elimination of waste and timely delivery of systems with immediate ROI.
|
Mark Lines
May 11, 2010 |
|
Successful Agile Needs Teamwork[article] Agile embraces the concept of self-organizing teams but they are inherently unstable and are only successful when the ‘Leadership – Self-Management’ dilemma is understood and dealt with. Too much central control destroys agility, inhibits creativity and resists change. Too much self-management leads to chaos and anarchy and destroys a team. A successful Agile Team needs to operate as far along the continuum towards self-management as it can, without tipping over into chaos. You can’t just eliminate the PM role and say to a software development team, “OK, you’re now an Agile Team – you need to self-organize”. This is a recipe for failure, and one of the reasons why many organizations resist the Agile approach.
|
||
SDLC 3.0 Provides a Platform for Method Integration[article] Even before written history, mankind has followed methods to invent, build, and use tools. As our tools have evolved so have our methods, and in today's software industry there are lots of articulations and communities built around software development methodologies. Despite the zealous beliefs within some of these communities, no single method is the silver bullet or the one truth from which to engineer and craft software in all contexts. |
||
Application Architecture Research[article] This article is mainly for developers, yet it doesn't cover specific languages or technology. The author details some tools that can help you learn the application's internal structure. Also included is an example of hook lib code, but it doesn't require deep development knowledge to understand. |
||
Active Following[article] Great leaders don't always lead the charge, stand in front, or offer direction. They know when to step aside to let others step forward. Yet, this type of leadership is often mistaken for passivity or overlooked entirely. Esther Derby shows how "in front" leadership actually can cause gridlock and loss of productivity and destroy the good spirits of a team. You can avoid these pitfalls by noticing when the most effective leadership means choosing to follow. |
||
When Is Communication Not Really Communication?[article] Complaints in the workplace about insufficient or inadequate communication are common, yet that very word "communication" is subject to multiple interpretations. Here's an example of what I mean: A director had a survey conducted to determine the cause of his employees' low morale. One of the key findings was their desire for more communication. Eager to put things right, the director began circulating more reports and email than ever. And as a voracious reader, he started to extract articles from his many periodicals and circulate them to everyone. |
||
Focus on Business Results[article] This article covers how to ensure that packaged software implementations focus on value-added business results. It also identifies the key techniques that we can employ in order to ensure that every project team member, and thus the project, focuses on the value-added business results. |
||
How Introverts and Extroverts Perceive Each Other[article] In this column, Naomi Karten describes an introvert and an extrovert whose communication styles led their coworkers to perceive them negatively. The way the two dealt with the situation—hoping that these perceptions would change—was useless. Naomi describes the important first step in creating positive perceptions. |
||
How to Focus on Business Results[article] This article covers how to ensure that packaged software implementations focus on value-added business results. It also identifies the key techniques that we can employ in order to ensure that every project team member, and thus the project, focuses on the value-added business results. |