In an Agile project are Product Owners leaders or drill sergeants? The role of Product Owner evolved out of the roles of project manager, business subject matter expert (SME) and project sponsor from the waterfall environment. In the waterfall model of projects, each of these roles provided different levels of direction, management and leadership. The project manager is the administrator. The SME provides information on what is done today and what they will need in the future. The sponsor’s role included providing resources, framing the scope of the project, providing direction as the project moves forward and to demand that the project delivers. The sponsor and the project manager are generally the outsiders that exhort the team into action . . . they act as drill sergeants. The Agile principle that states that “the business and developers must work together daily” suggests shedding the approach of an outsider exhorting the team and implementing the concept of the Product Owner as part of the team.

In an Agile project the Product Owner’s roles include

• Owning and prioritizing the product backlog
• Providing product vision
• Involving customers, users, and other stakeholders; and
• Collaborating with others on the team.

In my opinion the critical behavior is that of collaboration. Collaboration by definition is the act of working together to produce or create an outcome. The behavior of collaboration requires the Product Owner abandon the role drill sergeant and focus on being a leader.

The Product Owner leads by shaping the backlog and collaborating with their fellow team members. The qualities discussed in the Forbes article are very different from the attributes attributed to the screaming stereotypical drill sergeant. Is the Product Owner a leader or drill sergeant? The Product Owner will be more successful if they embrace the principle of the business and developers working together in collaboration, making them more of a leader than a drill sergeant.

 

In the preface of his book Essential Scrum, Kenneth Rubin writes “giving a new Scrum team just The Scrum Guide and expecting good results would be like giving a new chess player a 15-page description of the rules of chess and expecting her to be able to play a reasonable game of chess after reading it.” I like this analogy as the basic rules of Scrum seem simple, but a successful Scrum project, like a good chess game, depends on the ability to use these rules in the game context. ...

The twelve principles of the Agile Manifesto provide the basis for interpreting and implementing any Agile technique. One of the hardest principles for many organizations to adopt is:

“Business people and developers must work together daily throughout the project.”

Many implementation approaches have been designed to minimize the organizational inconvenience of this principal. Implementations range from embedding business users in the team to using proxies for the business to abandoning the principle altogether. The goal is to involve the business users (also know as the product owner in Scrum), so they can act as voice of the product. Fully embedding business personnel into the project team is often considered the most radical approach. However, is embedding radical or just not a one size fits all solution? I would suggest that embedding is a powerful tool therefore it can be perceived as radical. Because of the perception of this technique and the power it is not a one size fits all solution.

Embedding removes the product owner from their normal job and makes them part of a project team. This has an organizational cost which includes the cost of replacement ,even if replacement just means that other colleagues have to pick up the slack. A second, and more personal cost, occurs on long term projects. Embedded business personnel need a return path back to the business, or a path into the more technical world (the path I took once upon a time), or they risk career failure.

The costs of embedding are can be high. But, the benefits are generally equally large. The benefits, as we have discussed before, include intimacy of communication and reduction of project risk.

Should every project have a plaque memorializing embedded business personnel ? No, not every project requires embedded business personnel. Striking the balance between cost and value is part of the art of implementation. While this technique should be part of your Agile toolkit, I would not suggest that it should be a one size fits all solution..

Note: I am posting this Daily Process Thought from China. If the pictures are not perfectly aligned or missing, I will make corrections when I return.

Welecome to the Software Process and Measurement Cast 235

Over the past seven years at the end of every interview I have asked "what two issues would you fix and why" or some close variant of that question.  In that question each of my interviewees has left thier own mark on how I think about software process and measurement.  This week I am continuing with a walk down memory lane with three of the most popular segments from 2010.

In SPaMCAST
SPaMCAST 85 - Cory Foy, Agile Coaching, Collaboration Part 1
SPaMCAST 92 - Reinertsen, Product Development Flow
SPaMCAST 94 - Ivar Jacobson, SEMAT Part 1

I have also included an entry from the Daily Process Thoughts titled "Grief?"  

Daily Process Thoughts: Grief? , February 7, 2013

In the States it has become fairly common to find an impromptu memorial where a major traffic accident has occurred. I recently on a hike ran across a memorial to someone’s favorite dog. It has become easy and acceptable to memorialize loss. Kubler-Ross in her book “On Death and Dying” identified five stages of grief which include denial, arguing  bargaining, depression and acceptance  I would suggest that memorialization reflects acceptance.

Change and loss tend to follow similar paths. Memorializing how we worked in the past may well be a reflection of acceptance of what is being done now. As a change agent you do not need to react to every memorialization as a sign of push back.  Reflect carefully what is being really said and try to help your organization through acceptance.

The Daily Process Thoughts is my project designed to deliver a quick daily idea, thought or simple smile to help you become a better change agent. Each day you will get piece of thought provoking text and a picture or hand drawn chart to illustrate the idea being presented. The goal is to deliver every day; rain or shine, in sickness or in health or for better or worse! Check it out at www.tcagley.wordpress.com. 

Shameless Ad for my book! 

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team."

NOW AVAILABLE IN CHINESE! 

Have you bought your copy?

Contact information for the Software Process and Measurement Cast

Email:  spamcastinfo@gmail.com
Voicemail:  +1-206-888-6111
Website: www.spamcast.net
Twitter: www.twitter.com/tcagley
Facebook:  http://bit.ly/16fBWV

One more thing!  Help support the SPaMCAST by reviewing and rating the Software Process and Measurement Cast on ITunes!  It helps people find the cast. 

Next:

In the next SPaMCAST I will shift back to standard programming with an interview with Peter Talor, Ron Rosenhead and Vicki James in which we discussed thier new book, Strategies for Project Sponsorship.  Sponsors are not neccesarily born to the role and unless we want to take pot luck we better understand what makes a good sponsor.

The project is over, you’ve had the final retrospective and the team is beginning to think about what is next.  I have always that a celebration was an effective means of transitioning from one project to the next.  While the communal consumption of food as a team is a simple and powerful tool that should be part of your team-building toolkit, I have always found that stepping away from the ordinary pizza lunch and doing something a bit more out of the ordinary leaves a more  lasting impression. That lasting impression  can cement relationships and re-energize the team.

Many management pundits and social psychologists have remarked on the power of celebrating together. A simple twist I would like to suggest you occasionally try is the family potluck, each team member brings their favorite celebration dish.  One of my favorites is puff pastry wrapped brie with a cranberry reduction. A friend of mine is proud of his very special steamed dumplings filled with minced pork and red chilies (very spicy).  By including the team and their whole family we end up with cacophony of sights, tastes and noises, all of which helps create a deeper understanding of  who each person on your team really is.  I think we would all agree that our families or significant others are part of the broader team community.

Doing food as a team isn’t a new concept, but it never loses its luster. Take the next step and make your next celebration even better than the ordinary pizza lunch.

Post Thought Note:  It has been suggested that the word potluck  is code for the “boss is too cheap to buy me lunch.”  As leaders we nee to consider if that is our intent and if so we have a broader team problem a single project meal will fix.

Hand Drawn Graph Saturday

Imagine: A Venn diagram with three circles, misconceptions, decisions, and misinformation. Where all three overlap bad mistakes live!

Decisions made through a filter of misconceptions and based on imperfect knowledge generally lead to bad mistakes. All three of these concepts interact therefore changing even one can have a positive impact. What choices do we have to reduce the possibility of making a bad mistake?

First, in most situations we rarely have the time or the ability to gather all the knowledge necessary to have perfect information, therefore the best we can do is minimize the amount of imperfect information being used.

Secondly since we are human we are prone to misconceptions. A misconception is a mistaken belief. Misconceptions can be driven by many factors including culture, other beliefs, imperfect knowledge (yes, there is some co-variance) and poor communication.

Since many misconceptions are a reflection of poor communication. One way to avoid poor communication is to ensure that it is as intimate as possible. I would suggest a hierarchy of intimacy:

- Face-to-Face
- Video Conference
- Telephone
- Webinar / Teleconference
- Teleconference
- Text Chat
- Email
- Snail Mail

Fewer mistakes and even more importantly, fewer bad mistakes will happen if the intimacy of communications is increased. Every time you need to interact whether at work or at home ask yourself if you are using the most intimate communication channel available. If the answer is no, change the methods!

Note: I am posting this entry from China (really cool place)! If the images are garbled or missing I will fix them on my return.

Hand Drawn Graph Saturday

Imagine: A Venn diagram with three circles, misconceptions, decisions, and misinformation. Where all three overlap bad mistakes live!

Decisions made through a filter of misconceptions and based on imperfect knowledge generally lead to bad mistakes. All three of these concepts interact therefore changing even one can have a positive impact. What choices do we have to reduce the possibility of making a bad mistake?

First, in most situations we rarely have the time or the ability to gather all the knowledge necessary to have perfect information, therefore the best we can do is minimize the amount of imperfect information being used.

Secondly since we are human we are prone to misconceptions. A misconception is a mistaken belief. Misconceptions can be driven by many factors including culture, other beliefs, imperfect knowledge (yes, there is some co-variance) and poor communication.

Since many misconceptions are a reflection of poor communication. One way to avoid poor communication is to ensure that it is as intimate as possible. I would suggest a hierarchy of intimacy:

- Face-to-Face
- Video Conference
- Telephone
- Webinar / Teleconference
- Teleconference
- Text Chat
- Email
- Snail Mail

Fewer mistakes and even more importantly, fewer bad mistakes will happen if the intimacy of communications is increased. Every time you need to interact whether at work or at home ask yourself if you are using the most intimate communication channel available. If the answer is no, change the methods!

Note: I am posting this entry from China (really cool place)! If the images are garbled or missing I will fix them on my return.

Imagine: Imagine A sign asking the reader to stay out of the water when there is toxic aglae present and then finishing by exhorting the reader to have fun.

Some concepts just don’t work well together. Toxic algae and fun are one combination that at best sounds gross and at worst is dangerous.

Command and control and Agile are another potent conceptual mismatch. Agile, which is based on the 12 principles published with the Agile Manifesto, preaches self-organizing teams and motivated individuals. Concepts of self-direction and organization are at odds with being told how to work, as practiced by the command and control model. According to Harvard Management Update of April 10, 2006, command and control styles sap employee motivation because they rob people of respect, achievement and camaraderie.

Branding processes as agile and then layering on command and control management practices will exacerbate motivation problems rather than helping. Organizations that embrace Agile need to learn that trust is a more liquid currency than control. Trust and Agile are two concepts that work rather than fight each other.

Note: I am posting from China and the pictures may not be uploading correctly. I will correct any miss posts when I return.

Here is our monthly selection of interesting knowledge material on programming, software testing and project management: Web site: NASA Jet Propulsion Laboratory Java Coding Standard (PDF) Web site: Guidelines for Unit Testing Python Code Web site: The Agile Atlas Article: Basing Earned Value on Technical Performance (PDF) Article: Ten Tips for Constructing an Agile Database Development Environment that Works Article: Taking on a Project in Difficulties Article: Iteration Retrospective Activity: Turn the Tables Article: QTP Best Practices Article: Dot NET Assemblies and Strong Name Signature Tools: Zucchini, a visual iOS testing framework Tools: cipra, a C++11 unit testing framework Video: How Good ...

Imagine: A basket of plouts . . . what is a plout you might ask?

There are times when you just don’t have a clue. When I teach sizing (how big a piece of software or function is in story points or function points), I have noticed unless you give someone permission to say they don’t know, they have to have an opinion. The problem is that is if there is no basis for that opinion, how valuable is it? Bringing in a diversity of opinions and information can help to create more educated and nuanced opinions. Working in teams can encourage diverse opinions because each team member brings a different perspective to the discussion.

In his 2004 book, The Wisdom of Crowds, James Surowiecki asserted that the crowd, because of it diversity, could outperform individual decision-makers (note: this is a simplification of Surowiecki’s argument). In projects, the team is the crowd. The benefit of leveraging collective knowledge is greatest when the team has a diverse knowledge base to draw from. Diverse teams do not magically appear, they must be formed and then nurtured with diversity of thought and knowledge in mind.

When answering the question, “what is a pluot?” Google may well suffice, however when wrestling with the size of a web service to predict customer service times, you need a crowd.

Note: I am posting from China, if the pictures are missing or are garbled I will fix them when I return.

Imagine: A picture that exhorts you to wash your hands to keep from spreading colds or the flu.

The Agile technique of performing a retrospective at the end of every sprint is a powerful mechanism to understand the issues affecting your team. Part of the power of the technique is that since sprints are generally short (one to four weeks, with most being in the two week range), it is possible to address an issue as a team and then to expect quick feedback on progress toward resolution. The retrospective and washing your hands with soap and water are similar. Both represent a means to remove impurities that can sicken the team.

Note: I am publishing this blog from China. If the pictures are missing or garbled I will correct when I return.

We’ve decided to run a spring sale of our popular eLearning course: Agile Estimating and Planning. Until May 19, you can access the entire course , worth 4PDUs, for half off. Some of the things we cover include:

• The problem and the goal.
• Story points and ideal days.
• Estimating the product backlog.
• Release planning.
• Multi-team projects.

Here’s a sneak peek into the course – the intro:

You can access the course at your leisure from any of the following devices:

• Any modern operating system with the latest versions of Firefox, Internet Explorer, Safari or Chrome.
• iPads and iPhones.
• Android devices.

(Javascript must be enabled.)

To learn more or sign up, click the URL in the intro above.

Imagine: The central arrival hall at National Airport in Washington, DC, empty and in all of its startling beauty.

When highly polished design and function are melded together great things happen. Examples are not as rare as you might imagine, for example the iPhone and the iPad are well know examples of combining highly polished and function. Another is the main concourse at National Airport in Washington DC (Steve Jobs did not invent combining good design with function). The combination of design that approaches high art and function creates a connection between the product and its consumer.

Combining well-honed design with functionality is not always easy. The combining well-honed design and function requires extra effort and cost due the need to add different capabilities for teams that are generally stretched by the insatiable need for more user functionality. The pressure on information technology teams to deliver more functionality faster and cheaper will continue to push aside tasks that seem to be esoteric such as highly polished design.

Despite the challenges, when highly polished design and function do merge the resulting product or service can easily capture your customer’s imagination. Assuming that the product meets the needs of the market, by capturing your customer’s imagination you will build a base of loyalty. Research has shown a strong relationship between a well designed user experience and customer loyalty (For example see http://www.dmi.org/dmi/html/interests/strategy/06171GAR35.pdf) IT organizations are under continual pressure to reduces costs and to increase the efficiency of development methods. Unless we foster loyal and satisfied customers the deign decision will not be on investing in merging highly polished design and function but rather manufactured austerity. Less polished designs lead to lower satisfaction which lead even more cost and efficiency pressure. Merging highly polished design with function is not always an easy sell, but if you get it right your product or service will have a better shot at capturing attention and standing the test of time.

Note: I am publishing this blog from China. If the pictures are missing or garbled I will correct when I return.

Imagine: A sign with ALL the rules for the beach. A list just seems to go on and on.

The larger the number of rules, the lower the likelihood that any one will be able to knowingly follow all the rules. So, if the rules are really important, then enforcement (and the overhead required to support enforcement) is required. The enforcement requirements are the tax that reduce the overall amount of value that can be delivered if, as in most organizations, budgets are not unlimited. In a zero sum game, every additional check or level of oversight must be funded from somewhere.

Techniques like Agile espouse simpler processes and simpler enforcement mechanisms. One of the lessons we can learn from Agile is that focusing on the rules that really matter allows us to simplify the enforcement mechanisms. Less enforcement of arbitrary rules leaves us with more time to deliver value.

Now, what exactly is a swim diaper?

FYI: I am posting from China, if the photos are off or the timing is wonky I will correct when I get back.

Here is a list of software development related conferences and events that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine: STAREAST, April 28–May 3 2013, Orlando, USA GeeCON, May 15-18 2013, Krakow, Poland ICSE 2013, May 18-26 2013, San Francisco, USADevOps Summit Europe: Enabling DevOps, 23 May 2013, London, UK NxtGenTesting – Next Generation Testing conference, 23 May 2013, London, UK Android DevCon Spring, May 28-31 2013, Boston, USA Better Software & Agile Development Conference West, June 2-7 2013, Las ...

A few years ago I was asked by one of our customers to help them make better use of their integration layer. Ever since then me and my team have been working on a framework in support of that. This is the fourth in a series of blogs on the development of our framework, and discusses the features it provides. The one that was announced last time, about building blocks, is momentarily postponed.

So far I’ve discussed the goals & challenges surrounding the development activities, but I’d like to focus more on the framework itself now, and what it brings to those that are using it.

As soon as a new party (be it service consumer or service provider) connects to our framework, it can profit directly from the wealth of functionality we deliver out-of-the-box. These ‘generic features’ are exactly what one would expect from a (logical) ESB, and are partly based on the Expanded Enterprise Service Bus Pattern.

As our project was scrum driven, features were developed only when they were needed. Sometimes, during the design & build phase, we discovered a better way of doing things, and sometimes the problem a feature was supposed to address was solved in a completely different way, outside of our scope. But in the end we managed to implement about 20 features, which can roughly be divided into five types: routing, robustness, security, transformation and data storage.

Routing

One of our main objectives is to get messages from A to B without A having to know where B is currently residing. To do this, we make extensive use of the WS-Addressing standard. One of the components in our framework, the routing service, uses the information in the message headers to decide what the next hop will be (hop in this case being another framework component). Most of the times a message is delivered to the backside as soon as it enters the integration layer, something we call simple routing.

However, as soon as some special activity needs to be performed (like data model transformation for example), the message is detoured to one of the framework components not connected to the outside world. We classify those as intermediate services, and they are agnostic of nature – which means they have no clue about the context in which they are called. The necessary information for the message to continue its path is part of the addressing headers as well, making this advanced routing.

A special kind of advanced routing is distribution, which makes it possible to send one message to several subscribers at the same time, using WS-Notification in its most basic form. Finally prioritized routing is a feature which makes sure that a message gets ahead of the rest so to speak – very useful when dealing with a customer waiting for service at a counter while there’s also a bulk load being processed.

Robustness

Of course it’s of eminent importance that nothing goes wrong when delivering the message, or that when it does we can at least deal with the situation (exception management). First thing that happens when we receive a message is that we check to see if it complies with the industry & design standards we enforce (technical validation). Sometimes the consumer/publisher doesn’t want to wait for the (functional) answer but still wants to be informed if his message was technically valid, in which case we send him a response stating just that (technical acceptance).

Two of our features deal with peak load: throttling makes sure the integration layer only takes in what it can handle, while buffering guarantees we don’t overwhelm the applications we connect to. Similar to the second one is postponed delivery which is used when we know beforehand the backside is not available.

But by far the most important of these types of feature is guaranteed delivery. We played around with a bidirectional variant (using WS-RM) but finally settled on an unidirectional implementation, meaning that before we send the message we first store it, and if we receive an HTTP error code we send it again.

Last (and actually least, as it’s hardly used) it’s also possible to have syntactic validation of outgoing messages. But as we like to follow Postel’s law (also known as the robustness principle) we feel it’s the consumer’s responsibility to make sure the message was valid to begin with (you can imagine this took some selling from our part). The only exception is when the payload is altered by the framework.

Security

Every application that wants to connect to the integration layer needs to make itself known using the WS-Security UsernameToken (authentication). For most of the services we expose that’s enough, in a few rare cases such an application has to have explicit permission (authorization).

Not used internally (only when we receive requests from certain external customers) is integrity, where we demand that certain parts of the message headers and payload are signed.

Transformation

Given the fact that not all applications connected to the framework ‘speak the same language’ (as mentioned in the previous blog), there’s an evident need for data model transformation – one of our most used features. A lot less popular is the split feature, which makes it possible to divide a big message into smaller parts.

Data storage

The last few features play a more supportive role to the ones already mentioned. We provide logging to be used during testing & bug-finding sessions and persistence when there’s a need to store the complete message. The latter is frequently used in combination with resending (which is necessary for the guaranteed delivery feature described above), but also in case of auditing requirements.

Conclusion

Most of these features have been around since the first version of our framework, and have proven their generic qualities over time. In a few cases we had to make some alterations and even now there are one or two features which we might implement differently in the future. There’s also a list of additional features but it’s rather short, which I take as a sign that what we have here is pretty complete.

That’s number four; next time I’ll talk a bit about the more specific deliverables we provide our project teams.

Imagine: A boulder that has been painted white with a promise about the future written on it.

The promises made and kept define us. Agile asks us to say what we are going to do and then to do it. In the corporate environment this is an operational definition of integrity. The combination of making a commitment and the effort we put into meeting that commitment provide an emotional currency that that is far more meaningful than mere positional power when defining a leader.

FYI. Posting from China. If photos or timing are off I will correct when I get home.

Hand Drawn Chart Saturday

Imagine: A chart showing the flow of productivity as time goes by. The flow is interrupted by an event then begins against a higher level.

There are two basic strategies for process improvement, discontinuous and continuous (or incremental process improvement). While continuous change may have a large impact overtime, discontinuous changes, to use a baseball phrase, reflects a swing for the fence or a home run swing. Said another way, discontinuous change focuses on delivering lots of value quickly.

Discontinuous process improvement reflects a major change in how work is done. For example, an immediate shift from plan based development (waterfall) to Agile or shutting down mainframe and shifting to cloud computing.

Why would an organization assume the pain, effort and risk of discontinuous change? In some cases it is because the organization has no choice, it is either change or die. No other cases the organizational culture is more likely to embrace a single large change rather than many small changes. The goal of discontinuous process improvement is to reset the assumptions that underlie productivity through the introduction of a large unavoidable change. The change event creates an environment so that the behaviors and rules that generate a specific productivity can be changed so that the organization can deliver value more efficiently than before the change.

FYI: I am posting from China, if the photos are off or the timing is wonky I will correct when I get back.

Imagine: A mans head painted in black on a whitewashed boulder.

Without understanding the past, it is difficult to understand the big picture. All projects and organizations have a story and that story defines the arc of the project or organization. In order to anticipate the future, we must understand the full arc of the story. This is the crux of any project or organizational intervention. The questions that all leaders should ask themselves before the intervene are; “Can I effect the trajectory of the project or organization? And, will improve it the organization?”

The only way to fully answer those question is to consider the past. How much you consider it depends on circumstances. Acting without understanding the backstory will leave you wondering whether the actions taken were the best for all involved. Always dig for the story, techniques such as facilitated story telling or timeline retrospectives get the people you are talking to engaged in telling their story. Everyone has a story and enjoys telling it once they open up. Ask!

Note: If the pictures are missing or are garbled I am having trouble posting from Beijing.

Imagine: A fallen tree in a desolate spot in the woods.

When a tree falls in the woods and no one is around to hear it, does it make a sound? Physics tells us the answer is yes. Likewise, does the question about project progress not asked have a consequence? Project managers might not have as tidy an answer as physics professors. But not knowing could leave a hole in our knowledge or in the knowledge of the team, increasing the potential for a mistake. For example, as a product owner it is important to understand the acceptance criteria for a story to know if it is ready to be fully accepted. In both the short and the long term, what we don’t know can hurt us.

Note – the pictures are missing or garbled it is due to problems posting from Beijing