Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management

Community of Practice: Killers

A community of interest needs a common focus!

A community of interest needs a common focus!

All community of practices (COP) are not successful or at least don’t stay successful.  While there can many issues that cause a COP to fail, there are three very typical problems that kill off COPs.

  1. Poor leadership – All groups have a leader that exerts influence on the direction of the group. The best COP leaders I have observed (best being defined in terms of the health of the COP) are servant leaders.  In a community of practice, the servant leader will work to empower and serve the community. Empowerment of the COP is reflected by the removing of impediments and coaching the team so it meets its goals of connection, encouragement and sharing.  In COPs with a poor leader the goals of the group generally shift towards control of the message or to the aggrandizement of specific group or person.  Earlier in my career I was involved with a local SPIN (software process improvement network) group that had existed for several years.  The SPIN group was a community of practice that drew members form 20 – 30 companies in my area. At one point a leader emerged whose goal was to generate sales leads for himself.  Membership fell precipitously before a new leader emerged and re-organized the remnants.
  2. Lack of a common interest – A group put together without a common interest reminds me of sitting in the back of station wagon with my four siblings on long Sunday drives in the country.  Not exactly pointless but to be avoided if possible.  A community of practice without a common area of interest isn’t a community of practice.
  3. Natural life cycle – Ideas and groups have a natural life cycle.  When a COP purpose passes or fades, the group should either be re-purposed or shutdown. As an example, the SPIN mentioned above reached its zenith during the heyday of the CMMI and faded as that framework became less popular. I have often observed that as a COP’s original purpose wanes the group seeks to preserve itself by finding a new purpose. Re-purposing often fails because the passion the group had for the original concept does not transfer.  Re-purposing works best when the ideas being pursued are a natural evolutionary path.  I recently observed a Scrum Master COP that was in transition. Scrum was institutionalized within the organization and there was a general feeling that the group had run its course unless something was done to energize the group. The group decided to begin exploring Scaled Agile Framework as a potential extension of their common interest in Agile project and program management.

In general, a community of practice is not an institution that lasts forever. Idea and groups follow a natural life cycle.  COPs generally hit their zenith when members finally get the most benefit from sharing and connecting.  The amount of benefit that a member of the community perceives they get from participation is related to the passion they have for the group. As ideas and concepts become mainstream or begin to fade, the need for a COP can also fade. As passion around the idea fades, leaders can emerge that have other motives than serving the community which hastens the breakdown of the COP. When the need to a COP begins to fade, generally it is time to disband or re-purpose the COP.


Categories: Process Management

Software Development Linkopedia September 2014

From the Editor of Methods & Tools - Thu, 09/11/2014 - 09:36
Here is our monthly selection of interesting knowledge material on programming, software testing and project management.  This month you will find some interesting information and opinions about the software developer condition, scaling Agile, technical debt, behavior-driven development, Agile metrics, UX (user eXperience), NoSQL databases and software design. Blog: The Developer is Dead, Long Live the Developer Blog: Scaling Agile at Gilt Blog: Technical debt 101 Blog: Behaviour Driven Development: Tips for Writing Better Feature Files Article: Acceptance Criteria – Demonstrate Them by Drawing a House Article: Actionable Metrics At Siemens Health Services Article: Adapting Scrum to a ...

Xcode 6 GM & Learning Swift (with the help of Xebia)

Xebia Blog - Thu, 09/11/2014 - 07:32

I guess re-iterating the announcements Apple did on Tuesday is not needed.

What is most interesting to me about everything that happened on Tuesday is the fact that iOS 8 now reached GM status and Apple sent the call to bring in your iOS 8 uploads to iTunes connect. iOS 8 is around the corner in about a week from now allowing some great new features to the platform and ... Swift.

Swift

I was thinking about putting together a list of excellent links about Swift. But obviously somebody has done that already
https://github.com/Wolg/awesome-swift
(And best of all, if you find/notice an epic Swift resource out there, submit a pull request to that REPO, or leave a comment on this blog post.)

If you are getting started, check out:
https://github.com/nettlep/learn-swift
It's a Github repo filled with extra Playgrounds to learn Swift in a hands-on matter. It elaborates a bit further on the later chapters of the Swift language book.

But the best way to learn Swift I can come up with is to join Xebia for a day (or two) and attend one of our special purpose update training offers hosted by Daniel Steinberg on 6 and 7 november. More info on that:

Community of Practice: Owning The Message

Some time controlling the message is important!

Some time controlling the message is important!

The simplest definition of a community of practice (COP) is people connecting, encouraging each other and sharing ideas and experiences. The power of COPs is generated by the interchange between people in a way that helps both the individuals and the group to achieve their goals. Who owns the message that the COP focuses on will affect how well the interchange occurs. Ownership, viewed in a black and white mode, generates two kinds of COPs. In the first type of COP, the group owns the message. In the second, the organization owns the message. “A Community of Practice: An Example” described a scenario in which the organization created a COP for a specific practices and made attendance mandatory. The inference in this scenario is that the organization is using the COP to deliver a message. The natural tendency is to view COPs, in which the organization controls the message and membership, as delivering less value.

Organizational ownership of a COP’s message and membership are generally viewed as anti-patterns. The problem is that ownership and control membership can impact the COP’s ability to:

  1. Connect like-minded colleagues and peers
  2. Share experiences safely if they do not conform to the organization’s message
  3. Innovate and to create new ideas that are viewed as outside-the-box.

The exercise of control will constrain the COP’s focus which in an organization implementing concepts such self-organizing and self-managing team (Agile concepts) and will send very mixed messages to the organization.

The focus that control generates can be used to implement, reinforce and institutionalize new ideas that are being rolled out on an organizational basis. Control of message and membership can:

  1. Accelerate learning by generating focus
  2. Validate and build on existing knowledge, the organization’s message
  3. Foster collaboration and consistency of process

In the short-run this behavior may well be a beneficial mechanism to deliver and then reinforce the organization’s message.  The positives that the constraints generate will quickly be overwhelmed once the new idea loses its bright and shiny status.

In organizations that use top-down process improvement methods, COPs can be used to deliver a message and then to reinforce the message as implementation progresses. However, as soon as institutionalization begins, the organization should get out of the COP control business. This does not mean that support, such as providing budget and logistics, should be withdrawn.  Support does not have to equate to control. Remember that control might be effective in the short run; however, COPs in which the message and membership is explicitly controlled, in the long-term will not be able to evolve and support its members effectively.


Categories: Process Management

A Community of Practice: An Example And An Evaluation

A Community of Practice must has a have a common interest.

A Community of Practice must has a have a common interest.

I am often asked to describe a community practice.  We defined a community of practice (COP) as a group of people with a common area of interest to sharing knowledge. The interaction and sharing of knowledge serves to generate relationships that reinforce a sense of community and support.

An example of a recently formed COP:

Organizational context:  The organization is a large multinational organization with four large development centers (US, Canada, India and China). Software development projects (includes development, enhancements and maintenance) leverage a mix of Scrum/xP and classic plan based methods.  Each location has an internal project management group that meets monthly and is sponsored by the company.  This group is called the Project Manager COP (PMCOP).  The PMCOP primarily meets at lunchtimes at the each of the corporate locations with quarterly events early in the afternoon (Eastern time zone in Canada). Attendance is mandatory and active involvement in the PMCOP is perceived to be a career enhancement. Senior management viewed the PMCOP as extremely successful while many participants viewed it as little more than a free lunch.

Agile COP: The organization recently had adopted Agile as an approved development and software project management approach.  A large number of Scrum masters were appointed.  Some were certified, some had experience in previous organizations and some had “read the book” (their description). The organization quickly recognized that the consistency of practice was needed and implemented a package of coaching (mostly internal), auditing and started a COP with the similar attributes as the PMCOP. Differences implementation included more localization and self-organization.  Each location met separately and developed its own list of topics (this allowed each group to be more culturally sensitive) and each location rotated the meeting chair on a 3 month basis.  Participation was still mandatory (attendance was taken and shared with senior management).

In both cases the COP included a wide range of programming including outside presenters (live and webinar), retrospective like sessions and practitioner sharing.

In order to determine whether a COP is positioned to be effective, we can use the four attributes from Communities of Practice to evaluate the programs.  If we use the framework to evaluate the two examples in our mini-case study the results would show:

 

PMCOP Agile COP Common area of interest Yes, project management is a specific area of interest. Yes – ish, The COP is currently focused on Scrum masters; however, Agile can include a very broad range of practices therefore other areas of focus may need to be broken up. Process Yes, the PMCOP has a set of procedures for membership, attendance and logistics The Agile COP adopted most the PMCOP processes (the rules for who chairs the meeting and local topics were modified). Support Yes, the organization provided space, budget for lunch and other incidentals. Yes, the organization provided space, budget for lunch and other incidentals.  Note in both the Agile and PMCOP the requirement to participate was considered support by the management team but not by the practitioners. Interest The requirement to participate makes interest hard to measure from mere attendance.  We surveyed the members which lead to changes in programming to increase perceived value. The Agile COP had not been in place long enough to judge long-term interest; however, the results from the PMCOP was used to push for more local, culturally sensitive programming.

 

Using the four common attributes needed for an effective community of practice is a good first step to determine the strengths and weaknesses of a planned-to-be-implemented community of practice.


Categories: Process Management

The Main Benefit of Story Points

Mike Cohn's Blog - Tue, 09/09/2014 - 15:00

If story points are an estimate of the time (effort) involved in doing something, why not just estimate directly in hours or days? Why use points at all?

There are multiple good reasons to estimate product backlog items in story points, and I cover them fully in the Agile Estimating and Planning video course, but there is one compelling reason that on its own is enough to justify the use of points.

It has to do with King Henry I who reigned between 1100 and 1135. Prior to his reign, a “yard” was a unit of measure from a person’s nose to his outstretched thumb. Just imagine all the confusion this caused with that distance being different for each person.

King Henry eventually decided a yard would always be the distance between the king’s nose and outstretched thumb. Convenient for him, but also convenient for everyone else because there was now a standard unit of measure.

You might learn that for you, a yard (as defined by the king’s arm) was a little more or less than your arm. I’d learn the same about my arm. And we’d all have a common unit of measure.

Story points are much the same. Like English yards, they allow team members with different skill levels to communicate about and agree on an estimate. As an example, imagine you and I decide to go for a run. I like to run but am very slow. You, on the other hand, are a very fast runner. You point to a trail and say, “Let’s run that trail. It’ll take 30 minutes.”

I am familiar with that trail, but being a much slower runner than you, I know it takes me 60 minutes every time I run that trail. And I tell you I’ll run that trail with you but that will take 60 minutes.

And so we argue. “30.” “60.” “30.” “60.”

We’re getting nowhere. Perhaps we compromise and call it 45 minutes. But that is possibly the worst thing we could do. We now have an estimate that is no good for either of us.

So instead of compromising on 45, we continue arguing. “30.” “60.” “30.” “60.”

Eventually you say to me, “Mike, it’s a 5-mile trail. I can run it in 30 minutes.”

And I tell you, “I agree: it’s a 5-mile trail. That takes me 60 minutes.”

The problem is that we are both right. You really can run it in 30 minutes, and it really will take me 60. When we try to put a time estimate on running this trail, we find we can’t because we work (run) at different speeds.

But, when we use a more abstract measure—in this case, miles—we can agree. You and I agree the trail is 5 miles. We just differ in how long it will take each of us to run it.

Story points serve much the same purpose. They allow individuals with differing skill sets and speeds of working to agree. Instead of a fast and slow runner, consider two programmers of differing productivity.

Like the runners, these two programmers may agree that a given user story is 5 points (rather than 5 miles). The faster programmer may be thinking it’s easy and only a day of work. The slower programmer may be thinking it will take two days of work. But they can agree to call it 5 points, as the number of points assigned to the first story is fairly arbitrary.

What’s important is once they agree that the first story is 5 points, our two programmers can then agree on subsequent estimates. If the fast programmer thinks a new user story will take two days (twice his estimate for the 5-point story), he will estimate the new story as 10 points. So will the second programmer if she thinks it will take four days (twice as long as her estimate for the 5-point story).

And so, like the distance from King Henry’s nose to his thumb, story points allow agreement among individuals who perform at different rates.

The Main Benefit of Story Points

Mike Cohn's Blog - Tue, 09/09/2014 - 15:00

If story points are an estimate of the time (effort) involved in doing something, why not just estimate directly in hours or days? Why use points at all?

There are multiple good reasons to estimate product backlog items in story points, and I cover them fully in the Agile Estimating and Planning video course, but there is one compelling reason that on its own is enough to justify the use of points.

It has to do with King Henry I who reigned between 1100 and 1135. Prior to his reign, a “yard” was a unit of measure from a person’s nose to his outstretched thumb. Just imagine all the confusion this caused with that distance being different for each person.

King Henry eventually decided a yard would always be the distance between the king’s nose and outstretched thumb. Convenient for him, but also convenient for everyone else because there was now a standard unit of measure.

You might learn that for you, a yard (as defined by the king’s arm) was a little more or less than your arm. I’d learn the same about my arm. And we’d all have a common unit of measure.

Story points are much the same. Like English yards, they allow team members with different skill levels to communicate about and agree on an estimate. As an example, imagine you and I decide to go for a run. I like to run but am very slow. You, on the other hand, are a very fast runner. You point to a trail and say, “Let’s run that trail. It’ll take 30 minutes.”

I am familiar with that trail, but being a much slower runner than you, I know it takes me 60 minutes every time I run that trail. And I tell you I’ll run that trail with you but that will take 60 minutes.

And so we argue. “30.” “60.” “30.” “60.”

We’re getting nowhere. Perhaps we compromise and call it 45 minutes. But that is possibly the worst thing we could do. We now have an estimate that is no good for either of us.

So instead of compromising on 45, we continue arguing. “30.” “60.” “30.” “60.”

Eventually you say to me, “Mike, it’s a 5-mile trail. I can run it in 30 minutes.”

And I tell you, “I agree: it’s a 5-mile trail. That takes me 60 minutes.”

The problem is that we are both right. You really can run it in 30 minutes, and it really will take me 60. When we try to put a time estimate on running this trail, we find we can’t because we work (run) at different speeds.

But, when we use a more abstract measure—in this case, miles—we can agree. You and I agree the trail is 5 miles. We just differ in how long it will take each of us to run it.

Story points serve much the same purpose. They allow individuals with differing skill sets and speeds of working to agree. Instead of a fast and slow runner, consider two programmers of differing productivity.

Like the runners, these two programmers may agree that a given user story is 5 points (rather than 5 miles). The faster programmer may be thinking it’s easy and only a day of work. The slower programmer may be thinking it will take two days of work. But they can agree to call it 5 points, as the number of points assigned to the first story is fairly arbitrary.

What’s important is once they agree that the first story is 5 points, our two programmers can then agree on subsequent estimates. If the fast programmer thinks a new user story will take two days (twice his estimate for the 5-point story), he will estimate the new story as 10 points. So will the second programmer if she thinks it will take four days (twice as long as her estimate for the 5-point story).

And so, like the distance from King Henry’s nose to his thumb, story points allow agreement among individuals who perform at different rates.

Running unit tests on iOS devices

Xebia Blog - Tue, 09/09/2014 - 09:48

When running a unit test target needing an entitlement (keychain access) it does not work out of the box on Xcode. You get some descriptive error in the console about a "missing entitlement". Everything works fine on the Simulator though.

Often this is a case of the executable bundle's code signature not begin valid anymore because a testing bundle was added/linked to the executable before deployment to the device. Easiest fix is to add a new "Run Script Build Phase" with the content:

codesign --verify --force --sign "$CODE_SIGN_IDENTITY" "$CODESIGNING_FOLDER_PATH"

codesign

Now try (cleaning and) running your unit tests again. Good chance it now works.

Communities of Practice

Communities are all differnt

Communities are all different

Organizations are increasingly becoming more diverse and distributed while at the same time pursuing mechanisms to increase collaboration between groups and consistency of knowledge and practice. A community of practice (COP) is often used as a tool to share knowledge and improve performance. Etienne Wenger-Trayner suggests that a community of practice is formed by people who engage in a process of collective learning in a shared domain of human endeavor. There are four common requirements for a community of practice to exist:

  1. Common Area of Interest – The first required attribute for any potential community of interest must have is a common area of interest among a group of people. The area needs to be specific and an area where knowledge is not viewed as proprietary but can be generated, shared and owned by the community as a whole. When knowledge is perceived to be propriety it will not be shared.
  2. Process – The second must have attribute a community of practice needs is set of defined processes. Processes that are generally required include mechanisms to attract legitimate participants and the capture and dissemination of community knowledge.  The existence processes differentiate COPs from ad-hoc meetings.
  3. Support – There is a tendency within many organizations to either think of COPs as socially driven by users and self-managing or as tools to control, to collect and disseminate knowledge within the organization. In their purist form, neither case is perfect (we will explore why in a later essay) but in either case, somebody needs to take responsibility for the COP. The role is typically known as the community manager. The role of the community manager can include finding logistics support, budget, identifying speakers, capturing knowledge and ensuring the group gets together.
  4. Interest – Perhaps the single most important attribute required for any COP to exist is an interest in interacting and sharing. Unless participants are interested (passionate is even better) in the topic(s) that the community pursues they will not participate.

A community of practice tool promotes collaboration and consistency of practice even in organizations that are becoming more distributed and diverse. Communities of practice provide a platform for people with similar interests to build on individual knowledge to create group knowledge which helps organizations deliver more value.


Categories: Process Management

Xebia KnowledgeCast Episode 3

Xebia Blog - Mon, 09/08/2014 - 15:41

xebia_xkc_podcast
The Xebia KnowledgeCast is a bi-weekly podcast about software architecture, software development, lean/agile, continuous delivery, and big data. Also, we'll have some fun with stickies!

In this third episode,
we get a bit more technical with me interviewing some of the most excellent programmers in the known universe: Age Mooy and Barend Garvelink. Then, I talk education and Smurfs with Femke Bender. Also, I toot my own horn a bit by providing you with a summary of my PMI Netherlands Summit session on Building Your Parachute On The Way Down. And of course, Serge will have Fun With Stickies!

It's been a while, and for those that are still listening to this feed: The Xebia Knowledgecast has been on hold due to personal circumstances. Last year, my wife lost her job, my father and mother in-law died, and we had to take our son out of the daycare center he was in due to the way they were treating him there. So, that had a little bit of an effect on my level of podfever. That said, I'm back! And my podfever is up!

Want to subscribe to the Xebia KnowledgeCast? Subscribe via iTunes, or use our direct rss feed.

Your feedback is appreciated. Please leave your comments in the shownotes. Better yet, use the Auphonic recording app to send in a voicemessage as an AIFF, WAV, or FLAC file so we can put you ON the show!

Credits

Getting started with Salt

Xebia Blog - Mon, 09/08/2014 - 09:07

A couple of days ago I had the chance to spend a full day working with Salt(stack). On my current project we are using a different configuration management tool and my colleagues there claimed that Salt was simpler and more productive. The challenge was easily set, they claimed that a couple of people with no Salt experience, albeit with a little configuration management knowledge, would be productive in a single day.

My preparation was easy, I had to know nothing about Salt....done!

During the day I was working side by side with another colleague who knew little to nothing about Salt. When the day started, the original plan was to do a quick one hour introduction into Salt. But as we like to dive in head first this intro was skipped in favor of just getting started. We used an existing Vagrant box that spun up a Salt master & minion we could work on. The target was to get Salt to provision a machine for XL Deploy, complete with the customizations we were doing at our client. Think of custom plugins, logging configuration and custom libraries.

So we got cracking, running down the steps we needed to get XL Deploy installed. The steps were relatively simple, create a user & group, get the installation files from somewhere, install the server, initialize the repository and run it as a service.

First thing I noticed is that we simply just could get started. For the tasks we needed to do (downloading, unzipping etc.) we didn't need any additional states. Actually, during the whole exercise we never downloaded any additional states. Everything we needed was provided by Salt from the get go. Granted, we weren't doing anything special but it's not a given that everything is available.

During the day we approached the development of our Salt state like we would a shell script. We started from the top and added the steps needed. When we ran into issues with the order of the steps we'd simply move things around to get it to work. Things like creating a user before running a service as that user were easily resolved this way.

Salt uses yaml to define a state and that was fairly straight forward to use. Sometimes the naming used was strange. For example the salt.state.archive uses the parameter "source" for it's source location but "name" for it's destination. It's clearly stated in the docs what the parameter is used for, but a strange convention nonetheless.

We also found that the feedback provided by Salt can be scarce. On more than one occasion we'd enter a command and nothing would happen for a good while. Sometimes there would eventually be a lot of output but sometimes there wasn't.  This would be my biggest gripe with Salt, that you don't always get the feedback you'd like. Things like using templates and hierarchical data (the so-called pillars) proved easy to use. Salt uses jinja2 as it's templating engine, since we only needed simple variable replacement it's hard to comment on how useful jinja is. For our purposes it was fine.  Using pillars proved equally straightforward. The only issue we encountered here was that we needed to add our pillar to our machine role in the top.sls. Once we did that we could use the pillar data where needed.

The biggest (and only real) problem we encountered was to get XL Deploy to run as a service. We tried two approaches, one using the default service mechanism on Linux and the second using upstart. Upstart made it very easy to get the service started but it wouldn't stop properly. Using the default mechanism we couldn't get the service to start during a Salt run. When we send it specific commands it would start (and stop) properly but not during a run. We eventually added a post-stop script to the upstart config to make sure all the (child) processes stopped properly.

At the end of the day we had a state running that provisioned a machine with XL Deploy including all the customizations we wanted. Salt basically did what we wanted. Apart from the service everything went smooth. Granted, we didn't do anything exotic and stuck to rudimentary tasks like downloading, unzipping and copying, but implementing these simple tasks remained simple and straightforward. Overall Salt did what one might expect.

From my perspective the goal of being productive in a single day was easily achieved. Because of how straightforward it was to implement I feel confident about using Salt for more complex stuff. So, all in all Salt left a positive impression and I would like to do more with it.

SPaMCAST 306 – Luis Gonçalves, No More Performance Appraisals

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 306 Now

Software Process and Measurement Cast number 306 features our interview with Luis Gonçalves.  We discussed getting rid of performance appraisals.  Luis makes the case that performance appraisals hurt people and companies.

Luis’s Bio . . .

Luis Gonçalves is an Agile coach, author, speaker and blogger.

Luis has been working in the software industry since 2003, as an Agile practitioner since 2007. He has experience in integrating sequential project phases like localization into an Agile framework and pioneering Agile adoption at different companies and in different contexts.

Luis is the co-author of the book, Getting Value Out of Agile Retrospectives.

He has a technical background and is Management 3.0 passionate.

Mr Gonçalves likes to write and share ideas with the world and is a passionate blogger. Inspiration comes from his professional life and from the books he reads. Follow his blog at  http://lmsgoncalves.com/

Luis asks for SPaMCAST listeners to provide feedback on his new book, Get Rid of Performance Appraisals.

His mailing list is  http://eepurl.com/QGxfX  which provides the first part of his new book for free!

Next

Software Process and Measurement Cast number 307 features our essay on Agile integration testing.  Integration testing is defined as testing in which components (software and hardware) are combined to confirm that they interact according to expectations and requirements.  Good integration testing is critical to effective Agile development.

Upcoming Events

DCG Webinars:

Raise Your Game: Agile Retrospectives September 18, 2014 11:30 EDT Retrospectives are a tool that the team uses to identify what they can do better. The basic process – making people feel safe and then generating ideas and solutions so that the team can decide on what they think will make the most significant improvement – puts the team in charge of how they work. When teams are responsible for their own work, they will be more committed to delivering what they promise. Agile Risk Management – It Is Still Important! October 24, 2014 11:230 EDT Has the adoption of Agile techniques magically erased risk from software projects? Or, have we just changed how we recognize and manage risk?  Or, more frighteningly, by changing the project environment through adopting Agile techniques, have we tricked ourselves into thinking that risk has been abolished?

 

Upcoming: ITMPI Webinar!

We Are All Biased!  September 16, 2014 11:00 AM – 12:30 PM EST

Register HERE

How we think and form opinions affects our work whether we are project managers, sponsors or stakeholders. In this webinar, we will examine some of the most prevalent workplace biases such as anchor bias, agreement bias and outcome bias. Strategies and tools for avoiding these pitfalls will be provided.

Upcoming Conferences:

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested.

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

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.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

 

 

 


Categories: Process Management

Are Testers still relevant?

Xebia Blog - Sun, 09/07/2014 - 22:07

Last week I talked to one of my colleagues about a tester in his team. He told me that the tester was bored, because he had nothing to do. All the developers wrote and executed their tests themselves. Which makes sense, because the tester 2.0 tries to make the team test infected.

So what happens if every developer in the team has the Testivus? Are you still relevant on the Continuous Delivery train?
Come and join the discussion at the Open Kitchen Test Automation: Are you still relevant?

Testers 1.0

Remember the days when software testers where consulted after everything was built and released for testing. Testing was a big fat QA phase, which was a project by itself. The QA department consisted of test managers analyzing the requirements first. Logical test cases were created and were subordinated to test executors, who created physical test cases and executed them manually. Testers discovered conflicting requirements and serious issues in technical implementations. Which is good obviously. You don't want to deliver low quality software. Right?

So product releases were being delayed and the QA department documented everything in a big fat test report. And we all knew it: The QA department had to do it all over again after the next release.

I remember being a tester during those days. I always asked myself: Why am I always the last one thinking about ways to break the system? Does the developer know how easily this functionality can be broken? Does the product manager know that this requirement does not make sense at all?
Everyone hated our QA department. We were portrayed as slow, always delivering bad news and holding back the delivery cycle. But the problem was not delivering the bad news. The timing was.

The way of working needed to be changed.

Testers 2.0

We started training testers to help Agile teams deliver high quality software during development: The birth of the Tester 2.0 - The Agile Tester.
These testers master the Agile Manifesto, processes and methods that come with it. Collaboration about quality is the key here. Agile Testing is a mindset. And everyone is responsible for the quality of the product. Testers 2.0 helped teams getting (more) test infected. They thought like a researcher instead of a quality gatekeeper. They became part of the software development and delivery teams and they looked into possibilities to speed up testing efforts. So they practiced several exploratory testing techniques. Focused on reasonable and required tests, given the constraints of a sprint.

When we look back at several Agile teams having a shared understanding about Agile Testing, we saw many multidisciplinary teams becoming two separate teams: One is for developers and the other for QA / Testers.
I personally never felt comfortable in those teams. Putting testers with a group of developers is not Agile Testing. Developers still left testing for testers, and testers passively waited for developers to deploy something to be tested. At some point testers became a bottleneck again so they invested in test automation. So testers became test automators and build their own test code in a separate code base than development code. Test automators also picked tools that did not foster team responsibility. Therefore Test Automation got completely separated from product development. We found ways to help testers, test automators and developers to collaborate by improving the process. But that was treating the symptom of the problem. Developers were not taking responsibility in automated tests. And testers did not help developers designing testable software.

We want test automators and developers to become the same people.

Testers 3.0

If you want to accelerate your business you'll need to become iterative, delivering value to production as soon as possible by doing Continuous Delivery properly. So we need multidisciplinary teams to shorten feedback loops coming from different point of views.

Testers 3.0 are therefore required to accelerate the business by working in these following areas:

Requirement inspection: Building the right thing

The tester 3.0 tries to understand the business problem of requirements by describing examples. It's important to get common understanding between the business and technical context. So the tester verifies them as soon as possible and uses this as input for Test Automation and use BDD as a technique where a Human Readable Language is fostered. These testers work on automated acceptance tests as soon as possible.

Test Automation: Boosting the software delivery process

When common understanding is reached and the delivery team is ready to implement the requested feature, the tester needs programming skills to make the acceptance tests in a clean code state. The tester 3.0 uses appropriate Acceptance Test Driven Development tools (like Cucumber), which the whole team supports. But the tester keeps an eye out for better, faster and easier automated testing frameworks to support the team.

At the Xebia Craftsmanship Seminar (a couple of months ago) someone asked me if testers should learn how to write code.
I told him that no one is good at everything. But the tester 3.0 has good testing skills and enough technical baggage to write automated acceptance tests. Continuous Delivery teams have a shared responsibility and they automate all boring steps like manual test scripts, performance and security tests. It's very important to know how to automate; otherwise you'll slow down the team. You'll be treated the same as anyone else in the delivery team.
Testers 3.0 try to get developers to think about clean code and ensuring high quality code. They look into (and keep up with) popular development frameworks and address the testability of it. Even the test code is evaluated for quality attributes continuously. It needs the same love and caring as getting code into production.

Living documentation: Treating tests as specifications

At some point you'll end up with a huge set of automated tests telling you everything is fine. The tester 3.0 treats these tests as specifications and tries to create a living document, which is used for long term requirements gathering. No one will complain about these tests when they are all green and passing. The problem starts when tests start failing and no one can understand why. Testers 3.0 think about their colleague when they write a specification or test. They need to clearly specify what is being tested in a Human Readable Language.
They are used to changing requirements and specifications. And they don't make a big deal out of it. They understand that stakeholders can change their mind once a product comes alive. So the tester makes sure that important decisions made during new requirement inspections and development are stored and understood.

Relevant test results: Building quality into the process

Testers 3.0 focus on getting extreme fast feedback to determine the software quality of software products every day. Every night. Every second.
Testers want to deploy new working software features into production more often. So they do whatever it takes to build a high quality pipeline decreasing the quality feedback time during development.
Everyone in your company deserves to have confidence in the software delivery pipeline at any moment. Testers 3.0 think about how they communicate these types of feedback to the business. They provide ways to automatically report these test results about quality attributes. Testers 3.0 ask the business to define quality. Knowing everything was built right, how can they measure they've built the right thing? What do we need to measure when the product is in production?

How to stay relevant as a Tester

So what happens when all of your teammates are completely focused on high quality software using automation?

Testing does not require you to manually click, copy and paste boring scripted test steps you didn't want to do in the first place. You were hired to be skeptical about anything and make sure that all risks are addressed. It's still important to keep being a researcher for your team and test curiosity accordingly.

Besides being curious, analytical and having great communication skills, you need to learn how to code. Don't work harder. Work smarter by analyzing how you can automate all the boring checks so you'll have more time discovering other things by using your curiosity.

Since testing drives software development, and should no longer be treated as a separate phase in the development process, it's important that teams put test automation in the center of all design decisions. Because we need Test Automation to boost the software delivery by building quality sensors in every step of the process. Every day. Every night. Every second!

Do you want to discuss this topic with other Testers 3.0?  Come and join the Open Kitchen: Test Automation and get on board the Continuous Delivery Train!

 

SPaMCAST 306 - Luis Gonçalves, No More Performance Appraisals

Software Process and Measurement Cast - Sun, 09/07/2014 - 22:00

Software Process and Measurement Cast number 306 features our interview with Luis Gonçalves.  We discussed getting rid of performance appraisals.  Luis makes the case that performance appraisals hurt people and companies. 

Luis’s Bio . . .

Luis Gonçalves is an Agile coach, author, speaker and blogger.

Luis has been working in the software industry since 2003, as an Agile practitioner since 2007. He has experience in integrating sequential project phases like localization into an Agile framework and pioneering Agile adoption at different companies and in different contexts.

Luis is the co-author of the book, Getting Value Out of Agile Retrospectives

He has a technical background and is Management 3.0 passionate. 

Mr Gonçalves likes to write and share ideas with the world and is a passionate blogger. Inspiration comes from his professional life and from the books he reads. Follow his blog at  http://lmsgoncalves.com/

Luis asks for SPaMCAST listeners to provide feedback on his new book, Get Rid of Performance Appraisals.

His mailing list is  http://eepurl.com/QGxfX  which provides the first part of his new book for free!

Next

Software Process and Measurement Cast number 307 features our essay on Agile integration testing.  Integration testing is defined as testing in which components (software and hardware) are combined to confirm that they interact according to expectations and requirements.  Good integration testing is critical to effective Agile development. 

Upcoming Events

DCG Webinars:

Raise Your Game: Agile Retrospectives September 18, 2014 11:30 EDT Retrospectives are a tool that the team uses to identify what they can do better. The basic process – making people feel safe and then generating ideas and solutions so that the team can decide on what they think will make the most significant improvement – puts the team in charge of how they work. When teams are responsible for their own work, they will be more committed to delivering what they promise. Agile Risk Management – It Is Still Important! October 24, 2014 11:230 EDT Has the adoption of Agile techniques magically erased risk from software projects? Or, have we just changed how we recognize and manage risk?  Or, more frighteningly, by changing the project environment through adopting Agile techniques, have we tricked ourselves into thinking that risk has been abolished?

 

Upcoming: ITMPI Webinar!

We Are All Biased!  September 16, 2014 11:00 AM - 12:30 PM EST

Register HERE

How we think and form opinions affects our work whether we are project managers, sponsors or stakeholders. In this webinar, we will examine some of the most prevalent workplace biases such as anchor bias, agreement bias and outcome bias. Strategies and tools for avoiding these pitfalls will be provided.

Upcoming Conferences:

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested.

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

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.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

 

 

 

Categories: Process Management

There Is More To The Role Of A Project Sponsor

Sponsors ultimately say start or stop!

Sponsors ultimately say start or stop!

We defined the role of a project sponsor (or sponsors) as delivering resources, vision and political influence. This definition is in-line with my practical experience and for the most part within industry theory. I recently asked several colleagues, clients and friends their opinion of the role of the sponsor. While not a cross section of the IT environment, the sample included several published authors, developers, project managers, Scrum masters and even a few sponsors.

The results of this informal survey of the role of the sponsor was that sponsors:

  1. Deliver resources,
  2. Provide influence,
  3. Share vision,
  4. Are accountable for results and have the responsibility of delivering benefits back to the business, and
  5. Make the ultimate release decision.

The survey identified two concepts in addition to providing resources — influence and vision:

The first of the new concepts, accountability for results, reflects the idea that someone needs to make sure that the project delivers the promised benefits. Meetu Gururaj, Wipro, said it eloquently, “The sponsor has the responsibility of delivering benefits back to the business.” All significant projects are approved based on some sort of business case. The business case is used to allocate scarce resources (we can all agree that there is always more project work to do than budget available), knowledge and talent within the organization. If the results in the  business case becomes a mere formality used for project approval and then never referred to again, how is an organization to know whether they have made the right investment decision?

The second concept that the respondents added to the list of sponsor responsibilities was making the ultimate release decision. Evan Leybourn included in his ultimate role of the sponsor “is to say start and stop”. The sponsor supplies the budget/resources, the influence and support and is accountable for the results dovetailing nicely with making the ultimate go/no-go decision.

Sponsorship is more than writing a check and saying a few words of wisdom. The feedback from the sample of authors, developers, project managers, Scrum masters and sponsors was a reminder that the responsibilities of being a sponsor is balanced by accountability.


Categories: Process Management

Project Sponsor Anti-patterns

Some Anti-Patterns Should Be Avoided

Some Anti-Patterns Should Be Avoided

Wikipedia describes an anti-pattern as a response to a typical problem that is ineffective or potentially counterproductive. There are numerous ways to implement project sponsorship that work (patterns) and just as many that don’t work (anti-patterns). Reviewing the four of the most typical anti-patterns and some ideas on how to mitigate the negative impact is illustrative of the problems teams and organizations face.

  1. Absentee Sponsor: If you have not seen or talked to your sponsor in recent memory you are dealing with the problem of an absentee sponsor. Absentee sponsors can occur for a number of reasons including a project without an identified sponsor, a sponsor that is overburdened or an uninterested sponsor. Each specific cause requires a slightly different course of action; however the underlying cause generally is a problem of portfolio management. In many cases these problems are a reflection of starting more projects than the organization can work on effectively at one time. By starting too many projects the organization will struggle to either find sponsors that are directly interested in the project or can spend the time needed. One organization I worked with required a commitment to engage by a business sponsor before they would consider a project. Sponsors provide influence and resources needed by a project to be effective. Projects that fail this basic hurdle should be postponed. If an active project is suffering from an absentee sponsor, the project lead should, at the very least, escalate the issue as a critical risk as high up in organizational hierarchy as possible.
  2. Underpowered Sponsor: Underpowered sponsors can’t provide enough support, influence or resources for the project to effectively and efficiently deliver value. Underpowered sponsors usually are caused by two situations: The first, like absentee sponsors, is a reflection of a portfolio issue. The second issue is often a reflection of someone new to the ranks of senior management or the ranks of being a sponsor. The simplest solution to the second issue is for the “underpowered sponsor” to find an organizational ally (or allies) to augment their organizational power. A more radical solution would be to replace the underpowered sponsor; however, this should be a last resort solution and only used for critical projects.
  3. Proxy Sponsor: A proxy sponsor is a stand-in for the person that should be the sponsor. Proxy sponsors occur for many of the same reasons as absentee or underpowered sponsors; however, in this case someone has recognized the problem and tried to patch the problem. In many cases the “real” sponsor has delegated the responsibility for sponsorship either to IT or to his/her direct report. Decision-making in projects with proxy sponsors will take longer and will typically suffer from more interruptions from higher priority activities. Projects in this scenario should seek to identify decisions and support needs that are outside of the team’s span of control as early possible and avoid waiting for the escalation and validation process to catch up. One solution I suggest is that the proxy schedule periodic meetings which a more senior sponsor (a decision-maker) to ensure the wait time for decisions to be made is minimized.
  4. Role Conflict: Sponsors should not be project managers, Scrum masters or product owners. Occasionally, sponsors are seduced to the dark side and attempt to play one or more of these roles. Usually when a sponsor tries to play any of these roles on top of being the project sponsor (and in addition to their day job) they will be overwhelmed. In most cases the project leader should discuss the problem with the sponsor and ensure they have the proper training need to effectively act as a sponsor.

Effective project sponsorship is critical for any project to deliver the value described in project’s business case. The anti-patterns are most often a reflection of the poor portfolio management. Starting too many projects at once slows all projects down and typically means less gets done than if a more measured approach were taken. A project should not be started unless the right sponsor (which includes making sure they are trained to be a sponsor) is identified and they agree to take on the role. The right sponsor will be able to provide the right level of interest, influence and resources. Any other solution might help but will not solve the problem in the long run!


Categories: Process Management

Sponsors: The Resources, Influence and Interest Equation

Not everyone has what it takes to be a sponsor.

Not everyone has what it takes to be a sponsor.

Not everyone can or should be a sponsor. Good sponsorship requires resources, influence and interest in varying degrees.

Definitions:

Influence is the ability to make something happen or in some cases to make “things” not happen. Sponsors apply influence in a variety of ways including helping teams acquire resources or to remove barriers. Early in my career I had to ask a sponsor to make a call to get a schedule change so that my team did not have to move offices the week before a major production implementation. Influence can be used to remove barriers that are outside of the team’s control.

Resources, in their simplest form, begin with the check (budget) that the sponsor writes for the project. Managers transform the budget into a team, buy software, and secure team workspace or other project needs. Without resources, the duration of any project will be very short.

Interest is the feeling of wanting to learn more about the project which translates into attention, concern, or curiosity. The higher the level of interest in a project the more energy the sponsor will expend to pay attention to what is happening as the project progresses.

Project criticality, defined as the quality, state or degree of being of the highest importance, will impact the type of sponsor required. How does project criticality affect the need for specific levels of resources, influence and interest equation?

Untitled

Resources (at least over short to medium term) are closer to constant than a variable, either the project has the resources required or they do not. While there are theoretical discussions on the impact of somewhat constraining a project by providing them slightly less than what is requested, if a project does not have enough money they fail sooner or later. The higher the level of criticality more important the sponsor’s access to resources will be to ensure the project is not negatively constrained.

Criticality and the need for a sponsor to provide influence are positively correlated. The more critical a project, the more influence a sponsor may need to bring to bear to ensure focus and fend off distractions. Consider the impact to a project to a project if a team needs to be diverted to deal with urgent, but not important, interruptions. Interruptions rarely positively impact a project, and the higher the criticality the higher the chance that an avoidable interruption will impact the team or the project’s value.

While sponsors should be interested in any project they sponsor; the more critical a project is the more interest they will need to exhibit. Critical projects generally need the attention and involvement high levels of interest generate.   A sponsor that pays attention to project will be better positioned to provide support, motivation, influence and extra resources if needed.

Sponsors that cannot deliver the proper level resources, influence or interest for their projects will be poor sponsors. Projects of all types need to understand that because sponsors are human there will be variability in the amount of resources, influence and interest that can be brought to bear and attributes like criticality will required different levels of support. Project leaders and teams approach potential gaps in sponsorship as a risk, and should be assessed and mitigated if needed.


Categories: Process Management

Welcome to the Swift Playground

Xebia Blog - Thu, 09/04/2014 - 19:16

Imagine... You're working in swift code and you need to explain something to a co-worker. Easiest would be to just explain it and show the code right. So you grab your trusty editor and type some markdown.

let it = "be awesome"

Great!

So now you have a file filled with content:
swift-markdown

But it would be better if it looked like:

playground

Well you can and it's super simple, all you need is some Markdown and:

npm install -g swift-playground-builder

After that it's a matter of running:

playground my-super-nice-markdown-with-swift-code.md

Enjoy!

More info: https://github.com/jas/swift-playground-builder

A Project Sponsor Isn’t A Project Manager, Scrum Master or Product Owner!

Don't fall into the trap of assuming that the project sponsor can fill all roles.

Don’t fall into the trap of assuming that the project sponsor can fill all roles.

Project sponsors play a critical role in all projects. Sponsor’s  typically are senior leaders in an organization with operational roles that make playing multiple roles on a project difficult at best.  Project sponsors have the bandwidth to take on the project sponsor role, their day job and no other project role, therefore project sponsors are not project managers, Scrum masters or product owners.

Project managers develop plans, report and track progress, assign work and manage resources. Sponsors, on the other hand, provide direction and access to resources. Sponsors are informed by the project manager. On large or medium sized projects, the project manager role is generally a full-time position while the sponsor (generally a member of senior management) spends the majority of his or her time managing a portion of the business rather than a specific project.

In Agile projects the roles of the project sponsor and Scrum master are sometimes confused. A Scrum master facilitates the team. The Scrum master continuously interacts with the team ironing out the interpersonal conflicts, focusing the team on the flow of work and ensuring that nothing blocks the team from achieving their sprint goals. The sponsor provides motivation and exposure for the team at a higher level. A sponsor has issues and blockages escalated to them when they are outside of the team’s span of control. As with the project manager role, the Scrum master’s role provides intimate day-to-day, hour-to-hour support for the team while the sponsor is involved when needed or called upon.

Rarely is the sponsor the product owner. The only time I have seen the two roles combined is in very small organizations or in very small projects (and it wasn’t a great idea in either case). While both roles represent the voice of the business and the organization, a sponsor typically brings significantly more hierarchical power to the table. This positional power tends to dampen important Agile behaviors such as collaboration and self-organization. The product owner role will draw significantly on the time and focus of the project sponsor, which can cause them to take their eye off the direction of the business having negative ramifications.

As noted in The Role of The Project Sponsor, sponsors provide teams with a goal or vision, with access to resources and the political support needed to stay focused. The role can’t be played well by those in the organization without the needed sources of power, interest and resources needed to empower the project. Nor can someone play the role without the time needed to invest in the role. Project sponsors are typically senior leaders within an organization that are tied closely to the day-to-day operations of the organization, which makes it difficult if not impossible for them to play the role of project manager, Scrum master or product owner.


Categories: Process Management

SEMAT: The Essence of Software Engineering

From the Editor of Methods & Tools - Wed, 09/03/2014 - 17:37
SEMAT (Software Engineering Method and Theory) is an initiative to reshape software engineering such that software engineering qualifies as a rigorous discipline. SEMAT and Essence are big thinking for software developers. There are millions of software engineers on the planet in countless programs, projects and teams; the millions of line of software that run the world are testament to their talents, but as community we still find it difficult to share our best practices, truly empower our teams, seamless integrate software engineering into our businesses, and maintain the health of our ...