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

Scaling Agile – SAFe Agile Release Planning: Program Increment Objectives

Program increment (PI) objectives are summaries.

Program increment (PI) objectives are summaries.

Program increment (PI) objectives are summaries of business and technical goals at multiple levels within a program increment.  In the Scaled Agile Framework (SAFe) there are two levels of PI objectives. Team PI objectives reflect the summary of the specific business and technical goals that have been planned during release planning. Program PI Objectives are at a higher level of abstraction, reflecting the summary of the teams PI objectives to describe the overall program increment. The process of generating the PI objectives serves three primary purposes. They are to:

  1. Create alignment. Teams in the ART synthesize the visions (business context, product and architecture visions) presented at the beginning of the planning event along with the prioritized backlog to generate business and technical stories which are then planned. Stories and spikes are added and planned by the team until they reach capacity. When process of planning is complete the work that has been planned is summarized into the team PI objectives. PI objectives are communication vehicles for the team to share what they are doing to those outside the team and for other teams and stakeholders (those outside the team boundary) to consume and understand. The PI objectives are a stand in for a laundry list user stories that allows all of the ART teams to compare objectives.  The comparison process helps to ensure teams are aligned so that the program increment vision can be delivered. Program PI objectives are generated by synthesizing the teams PI objectives into program PI objectives. Program PI objectives are another tool to ensure all of the teams are aligned.
  2. Generate agreement of feasibility. The process of synthesizing the stories into team PI objectives and then from team PI objectives into program PI objectives is a mechanism to communicate what each team believes feasible in the program increment time frame. As team-level PI objectives are communicated and synthesized into program PI objectives, the ART has another opportunity to expose dependencies or to ensure that dependencies are understood.
  3. Set Expectations. PI objectives, whether at the team or program level, are commitments to perform. PI objectives can be thought of as line in the sand based on plans generated by the teams that are committed to doing the work (rather than plans and objectives made for the teams).

The release planning process is a mechanism for teams to plan the work they are going to do in a program increment. PI objectives are a mechanism to summarize the detail that planning creates so that everyone involved in the Agile release train can agree upon what will be delivered. At the end of a program increment those involved in the increment can reflect on the objectives both at a program and team level and use what was learned to continuously improve.


Categories: Process Management

SAFe Agile Release Planning: Participants Basics

Lots of varied roles!

SAFe’s release planning event is has been considered both the antithesis of Agile and the secret sauce for scaling Agile to programs and the enterprise. The process is fairly simple, albeit formal. Everyone involved with a program increment (an 8 – 12 week segment of an Agile release train) get together and synchronize on the program increment objectives, plan and then commit to the plan. Who is the “everybody” in a release planning event? The primary participants include:

  1. The Scrum Teams.   Release trains are typically comprised of 50 – 125 people with Scrum teams of 5 – 9 people comprising the lion’s share. Scrum teams are comprised of a Scrum master, product owner and technical personnel. The teams plan, identify risks and dependencies, share knowledge and commit to the plan.
  2. Release Train Engineer. The RTE facilitates the release planning meeting. The RTE is often called the Scrum master of Scrum masters. I have also heard the RTE called a cat herder.
  3. Product Management. Product management provides the vision for the program increment. They interpret the product roadmap and program epics providing direction.
  4. Business Owners. Business owners are the voice of the business. They interact with the teams in the ART to influence and generate an alignment between the program-level program increment objectives and the individual team-level program increment objectives.

Others that are involved include:

  1. CTO, Enterprise Architect and System Architect. These roles provide the architectural vision and an assessment of the Agile environment including changes since the beginning of the last program increment.
  2. Customer Representatives. Customer representatives are an adjunct to the product management personal providing interpretation of the vision.
  3. Release Managers. Release managers assist in planning, managing governing releases. The release manager may be involved in several ARTs.
  4. Engineering Development Managers. The development managers responsible for the applications involved in the release train need to be aware and provide support and knowledge capital to help ensure success.
  5. Tech Lead and Representative Team Members, Developers, QA/Test, Documentation, etc. Representatives from groups the ART must interface with during the program increment need to participate and have decision making power to commit personnel and resources needed to support the ART.
  6. VPs and Executives Responsible for Product Strategy, Delivery and/or other Affected Operations. Anyone that would typically need to review, provide support or resources or approve a plan or direction should be at hand during the release planning event.

It has been said that it takes a village to raise a child. It takes an equally complex number of roles and participants to plan and then generate commitment to that plan.


Categories: Process Management

Software Development Linkopedia November 2014

From the Editor of Methods & Tools - Tue, 11/18/2014 - 17:19
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 Agile coaching and management, positive quality assurance, product managers and owners, enterprise software architecture, functionnal programming, MySQL performance and software testing at Google. Blog: Fewer Bosses. More Coaches. Please. Blog: Advice for Agile Coaches on “Dealing With” Middle Management Blog: Five ways to make testing more positive Blog: 9 Things Every Product Manager Should Know about Being an Agile Product Owner Article: Managing Trust in Distributed Teams Article: Industrial ...

Are Vanity Metrics Really All That Bad?

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

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I have a bit of a problem with all the hatred shown to so-called vanity metrics.

Eric Ries first defined vanity metrics in his landmark book, The Lean Startup. Ries says vanity metrics are the ones that most startups are judged by—things like page views, number of registered users, account activations, and things like that.

Ries says that vanity metrics are in contrast to actionable metrics. He defines an actionable metric as one that demonstrates clear cause and effect. If what causes a metric to go up or down is clear, the metric is actionable. All other metrics are vanity metrics.

I’m pretty much OK with all this so far. I’m big on action. I’ve written in my books and in posts here that if a metric will not lead to a different action, that metric is not worth gathering. I’ve said the same of estimates. If you won’t behave differently by knowing a number, don’t waste time getting that number.

So I’m fine with the definitions of “actionable” and “vanity” metrics. My problem is with some of the metrics that are thrown away as being merely vanity. For example, the number one hit on Google today when I searched for “vanity metrics” was an article on TechCrunch.

They admit to being guilty of using them and cite such metrics as 1 million downloads and 10 million registered users.

But are such numbers truly vanity metrics?

One chapter in Succeeding with Agile, is about metrics. In it, I wrote about creating a balanced scorecard and using both leading and lagging indicators. A lagging indicator is something you can measure after you have done something, and can be used to determine if you achieved a goal.

If your goal is improving quality, a lagging indicator could be the number of defects reported in the first 30 days after the release. That would tell you if you achieved your goal—but it comes with the drawback of not being at all available until 30 days after the release.

A leading indicator, on the other hand, is available in advance, and can tell you if you are on your way to achieving a goal.

The number of nightly tests that pass would be a leading indicator that a team is on its way to improving quality. The number of nightly tests passing, though, is a vanity metric in Ries’ terms. It can be easily manipulated; the team could run the same or similar tests many times to deliberately inflate the number of tests. Therefore, the linkage because cause and effect is weak. More passing tests do not guarantee improved quality.

But is the number of passing tests really a vanity metric? Is it really useless?

To show that it’s not, consider a few other metrics you’re probably familiar with: your cholesterol value, your blood pressure, your resting pulse, even your weight. A doctor can use these values and learn something about your health. If your total cholesterol value is 160, a heart attack is probably not imminent. A value of 300, though, and it’s a good thing you’re visiting your doctor.

These are leading indicators. They don’t guarantee anything. I could have a cholesterol value of 160 and have a heart attack as soon as I walk out of the doctor’s office. The only true lagging indicator would be the number of heart attacks I’ve had in the last year. Yes, absolutely a much better metric, but not available until the end of the year.

So should we avoid all vanity metrics? No. Vanity metrics can possess meaningful information. They are often leading indicators. If a website’s goal is to sell memberships then number of memberships sold is that company’s key, actionable metric.

But number of unique new visitors—a vanity metric—can be a great leading indicator. More new visitors should lead to more memberships sold. Just like more passing tests should lead to higher quality. It’s not guaranteed, but it is indicative.

The TechCrunch article I mentioned has the right attitude. It says, “Vanity metrics aren’t completely useless, just don’t be fooled by them.” The real danger of vanity metrics is that they can be gamed. We can run tests that can’t fail. We can buy traffic to our site that we know will never translate into paid memberships, but make the traffic metrics look good.

As long as no one is doing things like that, vanity metrics can serve as good leading indicators. Just keep in mind that they don’t measure what you really care about. They merely indicate whether you’re on the right path.

Ready, Test, Go!

Xebia Blog - Tue, 11/18/2014 - 10:42

The full potential of many an agile organization is hardly ever reached. Many teams find themselves redefining user stories although they have been committed to as part of the sprint. The ‘ready phase’, meant to get user stories clear and sufficiently detailed so they can be implemented, is missed. How will each user story result in high quality features that deliver business value? The ‘Definition of Ready’ is lacking one important entry: “Automated tests are available.” Ensuring to have testable and hence automated acceptance criteria before committing to user stories in a sprint, allows you to retain focus during the sprint. We define this as: Ready, Test, Go!

Ready

Behaviour-Driven Development has proven to be a fine technique to write automated acceptance criteria. Using the Gherkin format (given, when, then), examples can be specified that need to be supported by the system once the user story is completed. When a sufficiently detailed list of examples is available, all Scrum stakeholders agree with the specification. Common understanding is achieved that when the story is implemented, we are one step closer to building the right thing.

Test

The specification itself becomes executable: at any moment in time, the gap between the desired and implemented functionality becomes visible. In other words, this automated acceptance test should be run continuously. First time, it happily fails. Next, implementation can start. This, following Test-Driven Development principles, starts with writing (also failing) unit tests. Then, development of the production code starts. When the unit tests are passing and acceptance tests for a story are passing, other user stories can be picked up; stories of which the tests happily fail. Tests thus act as a safeguard to continuously verify that the team is building the thing right. Later, the automated tests (acceptance tests and unit tests) serve as a safety net for regression testing during subsequent sprints.

Go!

That's simple: release your software to production. Ensure that other testing activities (performance tests, chain tests, etc) are as much as possible automated and performed as part of the sprint.

The (Agile) Test Automation Engineer

In order to facilitate or boost this way of working, the role of the test automation engineer is key. The test automation engineer is defining the test architecture and facilitating the necessary infrastructure needed to run tests often and fast. He is interacting with developers to co-develop fixtures, to understand how the production code is built, and to decide upon the structure and granularity of the test code.

Apart from their valuable and unique analytical skills, relevant testers grow their technical skills. If it cannot be automated, it cannot be checked, so one might question whether the user story is ready to be committed to in a sprint. The test automation engineer helps the Scrum teams to identify when they are ‘ready to test’ and urges the product owner and business to specify requirements – at least for the next sprint ahead.

So: ready, test, go!!

SAFe Agile Release Planning: Event Basics

OLYMPUS DIGITAL CAMERA

The release planning event in the Scaled Agile Framework Enterprise (SAFe) is a two-day program-level planning event that focuses the efforts of a group of teams to pursue a common vision and mission. As we have noted, the event includes participation by everyone involved in the Agile release train (ART), participation is in-person (if humanly possible), occurs every 8 – 12 weeks and has a formal structured agenda.   The agenda has five major components:

  1. Synchronization.  This component seeks to get everyone involved in the ART on the same page in terms of:
    1. Business Context
    2. Product Vision
    3. Architectural Vision
    4. Technical Environment and Standards

Each of these subcomponents provide the team with an understanding of what they are being asked to do and the environment they are being asked to operate within. The flow begins by grounding the team the business context for the program increment (the 8 -12 weeks). Each step after the business context increased in technical detail.

  1. Draft Planning. Leveraging the context, vision, architecture and environmental standards, the teams develop a draft plan. We will explore the process in greater detail in a later essay, however this where the team breakdown the stories they will tackle during the program increment, breaks them down, exposes risks and identifies and minimizes dependencies.   Draft planning usually consumes the second half of the day. The Release Train Engineer will gather the scrum masters together periodically during the draft planning process to ensure teams are sharing dependencies and understand the direction each is heading.
  2. Management Review and Problem Solving. At the end of draft planning, any significant problems with the scope of the program increment, staffing or other resource constraints are generally apparent. After the majority of team has completed their work for the day the management team (including RTE and scrum masters) meets to share what was learned and make the decisions needed to adjust to the constraints. This is must be completed before the beginning of day two.
  3. Final Planning. The teams review the adjustments made during the during the management review the previous evening as a whole group and then break out into teams again to continue planning converting the draft plans into final(ish) plans. Plans are finalized when they are accepted by the business owners.
  4. Review, Re-planning and Acceptance. When the teams plans are finalized they are reviewed by the whole team, the risks are ROAMed, the whole team votes on acceptance (a form of peer review and acceptance), any rework is performed on the plan and finally a retrospective is performed and next steps identified.

The release planning meeting operationalizes a program increment. A program increment represents 8 – 12 week planning horizon within a larger Agile Release Train. The large scale planning event helps keep all of the teams involved in the ART synchronized. The release planning meeting might be SAFe’s special sauce.


Categories: Process Management

SPaMCAST 316 – David Rico, Agile Cost of Quality

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 316

SPaMCAST 316 features a return visit from Dr. David Rico. We talked about the cost of quality and Agile. Does Agile impact the cost of quality? The cost of quality is a measure of the time and cost that is required to ensure that what is delivered meets quality standards. Dr. Rico walks us through the evidence that not only does Agile improve customer satisfaction, but it also improves the cost of quality.

Dr. Rico is a principal systems engineer with Boeing, where he helps oversee a portfolio of large, multi-billion dollar government computer-system programs. He has been a technical leader in support of NASA, U.S. Air Force, U.S. Navy, and U.S. Army for over 30 years. He has led numerous projects based on Cloud Computing, Lean Thinking, Agile Methods, SOA, Web Services, Six Sigma, FOSS, ISO 9001, CMMI, Baldrige, TQM, Enterprise Architecture, DoDAF, and DoD 5000. He specializes in IT investment analysis, IT portfolio valuation, and IT enabled change. He has been an international keynote speaker, presented at leading industry conferences, written seven textbooks, published numerous articles, and is a reviewer for multiple systems engineering journals. He is a Certified PMP, CSEP, ACP, CSM, and SAFe Agilist, and teaches at four Washington, DC-area universities. He has been in the field of information systems since 1983.

Contact Dr Rico
Blog:  davidfrico.com
Email: dave1@davidfrico.com
Twitter: @dr_david_f_rico

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change of on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

SPaMCAST 317 will tackle a wide range of frequently asked questions, ranging from the possibility of an acceleration trap, the relevance of function points, whether teams have a peak loads and safe to fail experiments.

We will also have the next instalment of Kim Pries’s column, The Software Sensei!

 

Upcoming Events

DCG Webinars:

How to Split User Stories
Date: November 20th, 2014
Time: 12:30pm EST
Register Now

Agile Risk Management – It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST
Register Now

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

SPaMCAST 316 – David Rico, Agile Cost of Quality

Software Process and Measurement Cast - Sun, 11/16/2014 - 23:00

SPaMCAST 316 features a return visit from Dr. David Rico. We talked about the cost of quality and Agile. Does Agile impact the cost of quality? The cost of quality is a measure of the time and cost that is required to ensure that what is delivered meets quality standards. Dr. Rico walks us through the evidence that not only does Agile improve customer satisfaction, but it also improves the cost of quality.

Dr. Rico is a principal systems engineer with Boeing, where he helps oversee a portfolio of large, multi-billion dollar government computer-system programs. He has been a technical leader in support of NASA, U.S. Air Force, U.S. Navy, and U.S. Army for over 30 years. He has led numerous projects based on Cloud Computing, Lean Thinking, Agile Methods, SOA, Web Services, Six Sigma, FOSS, ISO 9001, CMMI, Baldrige, TQM, Enterprise Architecture, DoDAF, and DoD 5000. He specializes in IT investment analysis, IT portfolio valuation, and IT enabled change. He has been an international keynote speaker, presented at leading industry conferences, written seven textbooks, published numerous articles, and is a reviewer for multiple systems engineering journals. He is a Certified PMP, CSEP, ACP, CSM, and SAFe Agilist, and teaches at four Washington, DC-area universities. He has been in the field of information systems since 1983.

Contact Dr Rico
Blog:  davidfrico.com
Email: dave1@davidfrico.com
Twitter: @dr_david_f_rico

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change of on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

SPaMCAST 317 will tackle a wide range of frequently asked questions, ranging from the possibility of an acceleration trap, the relevance of function points, whether teams have a peak loads and safe to fail experiments.

We will also have the next instalment of Kim Pries’s column, The Software Sensei!

 

Upcoming Events

DCG Webinars:

How to Split User Stories
Date: November 20th, 2014
Time: 12:30pm EST
Register Now

Agile Risk Management - It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST
Register Now

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

Re-read Saturday: Leading Change, John P. Kotter Chapter 2

You need to climb each stage to reach to top!

You need to climb each stage to reach to top!

 

We began exploring Leading Change by John P. Kotter by exploring the reasons organizational change fails. Chapter two explores successful change and the forces that drive successful change: an introduction to Kotter’s famous eight-stage process model and the role of leadership in change.

The eight-stage process for creating major change is a direct reflection of the eight common errors described in chapter one. The model describes a sequence of activities needed to generate, implement and then instantiate change within an organization. The eight steps are:

  1. Establish a sense of urgency.
  2. Creating a guiding coalition.
  3. Developing a vision and strategy.
  4. Communicating the change vision.
  5. Empower broad-based action.
  6. Generating short-term wins.
  7. Consolidating gains and producing more changes.
  8. Anchoring new approaches in the culture.

Each step in the model builds on the step before. Jumping into the model by communicating a vision and strategy with a power base and an organizational urgency is like putting the cart before the horse. The strategy and vison you are trying to communicate will not have the motivational power and would easily run out gas. When considering the stages in the model, recognize that Kotter conceived of the model as a sequence and that each step needs to be addressed.

Kotter talked briefly in the chapter about projects within projects. The idea is that most major changes are a reflection group of inter-related changes. An IT program is a group of related projects managed in a coordinated fashion. Any project can be starting or completing if we looked at a cross section of the program at any specific time. Similarly any individual change project following Kotter’s process within a larger group of changes will be at the stage need by that project.

The second major theme in this chapter is a discussion of leadership and the differences between leadership and management. Leadership provides vision and direction that are needed for building a powerbase for change and then to galvanize the organization into action. Almost by definition a leader conceives of a vision of the future and then acts as a catalyst to make that vision a reality. Leadership is transformational in nature. The difficulty is that many change programs are led by managers rather than leaders. Management is concerned with organizing, planning and controlling work. Almost by definition management is a tool to resist change. Management is important to the day-to-day activities, but without the vision of leadership there would be nothing to manage. Where leadership transforms, management translates.

While the dichotomy of leadership and management seems black and white, both are always required in any organization. As the rate of change increases (or at least as the need for the rate of change increases), the need for vision and leadership increases. Alternately during periods in were there is little pressure on firms business model, the need for managers and management tends to rise into ascendancy over the need for leadership. The late 40’s and 1950’s were such a period in the United States. That is not the environment that we find ourselves in today. Change is a fact of life. Kotter’s eight-stage process model provides a structure for applying leadership in consistent manner that identifies why change needs to occur, builds a base, delivers change and makes sure it sticks.


Categories: Process Management

Social Media and Process Improvement

Collaboration tools are now nearly ubiquitous in the home, in the workplace and on your belt. These tools are wielded by a generation that has grown up using text/SMS messages.

Collaboration tools are now nearly ubiquitous in the home, in the workplace and on your belt. These tools are wielded by a generation that has grown up using text/SMS messages.

A piece of advice I once received was that you either made things happen or let them happen to you. That piece of advice is as true now as it was then.  We live in an era of great change inside and outside the information technology community.  The advent of social media and its incorporation into workplace to foster collaboration is only one affectation of the change that is going on.  There are many messages the explosion of social medias such as LinkedIn, Facebook, blogs and podcast can share with the process improvement (PI) community.   The first and perhaps the most important message is transmitted by the extraordinary fact these tools exist at all.   The fact that these tools exist (not even reflecting on the fact that there are five more everyday) is that change is occurring and that it is unstoppable because it fits human nature. These changes are not only unstoppable, but gaining speed.  The change driven by social media is a very human kind of change which affects how people interact and how work is accomplished.  In the process improvement arena both you and your customers are the change.  This a statement on many levels.  I would like to focus on what the changing environment says about a changing vision of control.  Control is a critical concept in the process improvement community and the change I see in our industry is redefining the concept of control or at the very least challenging how control can be applied.

At its basic level control is a gate that interjects “permissions” between two groups.  For example, defining a process for tailoring a defined methodology for use on a project creates a control gate that regulates how work will be accomplished. The process defines the ritual required to granted permission to change the standard process.  The world that created these control gates is quickly being overcome by a new set of rules that govern collaboration and social interaction.  Workers in this new world can easily view permissions as a hurdle between them and getting the work done.  This is most true when control gates add drag to the process without adding perceived value.  This conflicts with an alternative, albeit more classic, view of organizational control, where relying on the wisdom of crowds or where a wide distribution of authority is view as contributing to anarchy.  The second paradigm is one that we have been trained to accept as true by models such as the CMMI or tools like Six Sigma.  It is the view that standardization is good and control is required for standardization therefore anything that challenges control leads to a suboptimal outcome.   I suggest that a change in paradigm is at our door, it is knocking and it isn’t going to leave. Change is inevitable and since we are the change, we can help guide change in our organizations and our industry or ride the wave and let change happen to us.


Categories: Process Management

Social Media and Process Improvement

Collaboration tools are now nearly ubiquitous in the home, in the workplace and on your belt. These tools are wielded by a generation that has grown up using text/SMS messages.

Collaboration tools are now nearly ubiquitous in the home, in the workplace and on your belt. These tools are wielded by a generation that has grown up using text/SMS messages.

A piece of advice I once received was that you either made things happen or let them happen to you. That piece of advice is as true now as it was then.  We live in an era of great change inside and outside the information technology community.  The advent of social media and its incorporation into workplace to foster collaboration is only one affectation of the change that is going on.  There are many messages the explosion of social medias such as LinkedIn, Facebook, blogs and podcast can share with the process improvement (PI) community.   The first and perhaps the most important message is transmitted by the extraordinary fact these tools exist at all.   The fact that these tools exist (not even reflecting on the fact that there are five more everyday) is that change is occurring and that it is unstoppable because it fits human nature. These changes are not only unstoppable, but gaining speed.  The change driven by social media is a very human kind of change which affects how people interact and how work is accomplished.  In the process improvement arena both you and your customers are the change.  This a statement on many levels.  I would like to focus on what the changing environment says about a changing vision of control.  Control is a critical concept in the process improvement community and the change I see in our industry is redefining the concept of control or at the very least challenging how control can be applied.

At its basic level, a control is a gate that interjects “permissions” between two groups.  For example, defining a process for tailoring a defined methodology for use on a project creates a control gate that regulates how work will be accomplished. The process defines the ritual required to granted permission to change the standard process.  The world that created these control gates is quickly being overcome by a new set of rules that govern collaboration and social interaction.  Workers in this new world can easily view permissions as a hurdle between them and getting the work done.  This is most true when control gates add drag to the process without adding perceived value.  This conflicts with an alternative, albeit more classic, view of organizational control, where relying on the wisdom of crowds or where a wide distribution of authority is view as contributing to anarchy.  The second paradigm is one that we have been trained to accept as true by models such as the CMMI or tools like Six Sigma.  It is the view that standardization is good and control is required for standardization therefore anything that challenges control leads to a suboptimal outcome.   I suggest that a change in paradigm is at our door, it is knocking and it isn’t going to leave. Change is inevitable and since we are the change, we can help guide change in our organizations and our industry or ride the wave and let change happen to us.


Categories: Process Management

A Simple Tool: A pep talk

It takes a good attitude to be a good leader.

It takes a good attitude to be a good leader.

As a leader of people is easy to become weary to your bones after trying to convince a reticent organization, team or person to become a butterfly, when all they want to do is to stay in their nice safe cocoon. The forces lined up against you can be daunting. Don’t work against yourself by making your attitude part of the problem. Your attitude is one of your primary tools to lend credibility to your message and convince people to engage and befriend you. There are three attributes you need to consider managing immediately: negativism, sarcasm and partisanship.

Negativism is a habitual attitude of skepticism or resistance to the suggestions, order or instructions of others. This includes change and the belief that change is warranted or even possible. Leading change requires that you believe that you can succeed to motivate yourselves and those you are trying to influence. Without a belief that you can succeed, it will be difficult to get up in the morning and impossible to motivate others. I must at admit that I sometimes find that it is easy to confuse being highly rational with negativism. In the wee hours of the night make sure you evaluate which side of the line you are on and make corrections if you have strayed.

Behavior such as sarcasm might be acceptable amongst friends, but the impact of sarcasm is even less predictable when people do not know you or might have a different cultural filter are involved in the conversation. How many time have you heard “hey can’t they take a joke?” The answer is maybe not if it is apparently funny to their point of view. Frankly, just dropping sarcasm from your portfolio of communication techniques might be the best idea.

Another critical mistake that can be traced back to attitude is a need to have an enemy to strike against. Creating a “we/they” environment creates barriers between groups will make finding common ground more difficult. There are rarely benefits when one side is forced to capitulate to another (it difficult to compromise with someone you view as the enemy). You must recognize that as a leader and a negotiator your goal is to find the best solution for your organization.

Negativism, sarcasm and partisanship will minimize your effectiveness as a leader in the long run, and will add to the burden you need to shoulder in order to make change happen. Leading change is not an easy job. Don’t make it harder than it needs to be. Your attitude can either a simple powerful tool or concrete block to tow behind you.


Categories: Process Management

Focus: Short-term Help

Getting work done is directly related to focus.

Getting work done is directly related to focus.

The discussion of hyper-connectivity and the techniques to combat the downside of hyper-connectivity has convinced me that in many cases we are dancing around the bigger workplace issue of how can you stay focused on delivering real business value in an environment that seems to be designed to promote making incremental progress on lots of projects rather than getting any one of them done. For those that are not steeped in the theory of lean, that translates to making progress on lots of tasks without finishing the bigger project to which the tasks belong. This focus on activity might be an artifact of workplace cultures that have been downsized and are attempting to get more done with less or the management by objective type behaviors that foster generating silo behaviors. Regardless of workplace I have observed this type of behavior different national cultures. For example, in conversations with Brazilian and Indian friends they have told me the same story of having to juggle multiple priorities and finding it difficult to stay focusing. The causes of the problem include: the after effects of downsizing, a belief in multitasking, lack of prioritization or plain poor management. These are important to understand for a long-term solution, however in the short-term, tactics are needed to generate focus in order to get into the flow! A few of the techniques I use or have been shared to help generate focus include:

  • Organize your workspace to avoid distractions – Clutter is not your friend. My desk is a hodgepodge of pictures, magazines waiting to read, piles of paid bills, several monitors, hard drives, microphones and an audio mixer. All sorts of cool and interesting stuff that screams for attention. I don’t do work that requires focus in my office anymore. The dining room table that no one uses provides an austere environment that promotes focus. I go back to my office to play.
  • Prepare to focus – A friend that writes for a living suggested that you have what you need close at hand before you start on a task. In other words, get that cup of coffee, tea or water before putting pen to paper or fingers to keyboard. Preparation includes making sure you laptop is plugged in or has a charge and literally visiting the bathroom upfront.
  • Have a routine – Frameworks like Scrum or Kanban have a very specific, built-in routine. Each project, release, sprint and day begin with a planning exercise. Time management technique like Getting Things Done (GTD) include planning specific next steps as soon as the previous step is completed. In recent Slate Working Podcast titled The “How Does a Cartoonist Work?” Edition, David Plotz interviewed Washington Post cartoonist, Tom Toles. Mr Toles said that he learned early on that routine was required to continually generate creative content. Routine liberated him from have to think deeply about mundane decisions that needed to be made on a day basis, allowing more time to be work on what really delivered value.
  • Plan – A corollary to having a routine. Plan and re-plan as needed. If nothing else, spend the first few minutes of every day planning the day ahead, and then re-plan as “stuff” happens.
  • Share your “rules” – If you work in a team and you are going to try techniques like the 20 minute sprint or the two email rule, let your friends, co-workers and boss know what you are doing. Also consider asking for their support in enforcing the techniques (thanks to Mauricio Aguiar for the addendum).
  • Airplane mode – While listening to an introduction to a speaker at the Brazilian Metricas 2014 conference, the conference chair suggest to the audience that turning their phones on airplane mode was a better choice than setting their phones to silent.  Airplane mode would ensure they were not interrupted so that they could pay proper attention.  Point well made.

In a response to Hyper-connectivity and The Illusion of Progress, Gene Hughson stated “The illusion of importance also applies in that the need for constant connection can be a conceit – “I’m too important to be out of touch, even for a minute”.” That conceit can lead to a reduction in productivity and effectiveness that hurts everyone. Re-focusing on focus requires sacrificing some of the distractions that make us feel that we are at the center of the importance universe (at least for 20 minutes at a time).


Categories: Process Management

7 Articles On Risk Management in Software Development

From the Editor of Methods & Tools - Wed, 11/12/2014 - 16:20
While starting a new software development project creates some enthusiasm, the engineer part of the software developer and project manager will also see this event as a set of possible risks. These risks encompass many domains: business, project team, software architecture, technology… Besides being aware of the possible impediments to the project success, risk management is also used to make choices in the product and technology roadmaps and manage priorities when resources are limited. Here is a list of interesting articles that discusses approaches to risk in software development. Risk Management ...

Tactics for Combating the Downside of Hyper-connectivity

The genie of hyper-connectivity is not going to go back in the bottle, and moving to a mountain deep in the woods is not a career enhancing solution (unless you are writing a novel).

The genie of hyper-connectivity is not going to go back in the bottle, and moving to a mountain deep in the woods is not a career enhancing solution (unless you are writing a novel).

All the activity that is generated in a hyper-connected world can lead to the illusion of progress, to an illusion of importance and to force ineffective multitasking. Trying to put the genie totally back in the bottle would be difficult at best, since hyper-connectivity can be useful in the right circumstances. Measured steps can be used temper the some of the more problematic attributes of hyper-connectivity.

  1. Electronics free meetings. Specify some meetings as laptop and cell phone closed. Remove the potential distraction of the texting, email and other work by using the nuclear option. Recently I participated in a meeting that had a diverse set of participants most with different cultures and first languages. All of the participants were asked to close their laptops. Participation in the group increased even though one or two “members” were very reticent. While there were exceptions for long meetings, such as more frequent break to check in with the electronic masters or allowing the person with a kid at home sick to have an exemption, cutting the cord in meetings seems to have merits. In response to the article Hyper-connectivity and The Illusion of Progress, Chris noted:

I’ve been saying (and promoting) this for years as well. In a previous role, with Software Configuration Management, Build & Release, and QA Engineers reporting to me, I mandated that our weekly, short, team meetings were spend untethered to smart phones and laptops, except for the person charged with taking team notes. Very effective!

  1. Twenty minute sprints. Turn off the connections (think airplane mode) for twenty minutes. At the end of the twenty minute period turn them back on, open Outlook and read/respond for 5 – 10 minutes then repeat. I will admit that I am a connectivity addict, but this has become one of my favorite techniques to reduce connectivity distractions. I have settled on the twenty-minute rule because the time frame is long enough that I can get real work done and short enough not induce panic from being cut off. Note, I have modified the rule to allow going to the internet to look up a fact or to find a synonym (if I am not in my office with a paper thesaurus). The sprint technique has been used at more macro level in some organizations with days without email or meetings.
  2. Don’t reply to emails after hours. Compartmentalize your work and home lives when possible. Some companies such as the Volkswagen, Puma and BMW have tried this technique in an attempt to reduce the burnout hyper-connectivity can generate. I have not found any data to suggest the technique has been effective and obviously there are a few issues that are critical enough to require a response (FYI . . . I suggest picking up the phone and calling someone in those circumstances). This technique help create separation between home and work life and slow down the the expectation of immediate actions and responses.  .
  3. The Two-Email Rule. If a discussion or issue spans two emails or text messages, call the person or persons involved in the discussion and talk. I personally have begun to try to implement this rule and have found it very effective in reducing text or emails being volleyed back and forth without resolving anything. When emails are being volleyed back and forth it seems like the progress is measured by passing the issue on rather than resolving it. The biggest issue I have found is that in some circumstances people are using the volley technique to avoid having difficult conversations.

The genie of hyper-connectivity is not going to go back in the bottle, and moving to a mountain deep in the woods is not a career enhancing solution (unless you are writing a novel). There are a number of techniques that can create an oasis in the communication storm. You can practice some of these  techniques individually and change your own behavior.  When you are working on a team, change will require a vision of the future and leadership to make even incremental changes to how work is done by the team.


Categories: Process Management

The neverending waveform of the full-stack developer

Xebia Blog - Tue, 11/11/2014 - 16:50

There was an article on Techcrunch a couple days ago which was linked in our internal mailing list the other day, titled The Rise And Fall Of The Full Stack Developer. I read it, and I just couldn't figure out why the title is about "the fall" of the full-stack developer (and I said as much on the mailing list, after which I was encouraged to write this blog post). In this post I'll try and explain why it's not the end, but just a stage in a recurring cycle

What I read was a waveform - the article describes that first you had low-level assembly, which is specialised but still pretty straightforward since it's just one platform and language. Then things started to get more complicated, with the larger web applications involving lots of experts in various fields (Java, database management, server and JVM management, to name a few from the article).

In or around 2005, there was a bit of a revolution going on. Internet access (and high-speed internet for that matter) became accessible to all, and with it, cheap webhosting - most notably, there was a boom in PHP development. What the article highlights is that that was an era where single or small teams of developers could build a web application from scratch, without needing to lug around all of that expert knowledge - effectively, a full-stack developer (storage, webhosting, a programming language (PHP, Python, Ruby, etc), HTML, CSS, Javascript, the whole stack).

But, as the article states, that isn't the full stack of today - added to that are things like machine learning, mobile development, more advanced and less traditional programming languages, frameworks and persistence solutions, etcetera. The conclusion of the author is that it's too much for one full-stack developer to take, that there's no way a full-stack developer can be an expert in all of those fields - and he basically renames the person that knows a bit of all of those technologies a full-stack integrator, and declares the full-stack developer dead.

But I didn't see that. What I saw was just history repeating - from simple and manageable, to complex and too much for one person to handle and know all about. From assembly and PHP, to Java enterprise software and Docker-contained AWS instances running a MongoDB and Scala REST interface to power your Android, iOS and single-page AngularJS-powered webapps (to name but a few buzzwords).

I'm sure the next 'simple' wave is already around the corner - maybe it's already here, lurking somewhere until some more influential guy goes "Hey guys, let's go back to the simpler, good old times where you wrote code and it Just Worked™!", where a wave of developer will follow - most likely a combination of younger people, new to the software development world, and older people that have been stuck in an overly complicated software development rut for far too long.

As for not being able to keep up with it all, this is why it's probably better to assemble teams out of T-shaped developers - full-stack developers with a broad knowledge set (and more importantly, broad interests and curiosity), but with at least one specialisation. This was extended within Xebia to pi-shaped developers, then made extreme to comb-shaped developers, but the latter is just a generalist like mentioned in the article - a jack of all trades, master of none. And it's important to realise, as a developer, that it's OK to not know everything, to miss some update, to not learn that fancy new programming language by people disgruntled by Java's slow development - there's simply too much information updates today, and trying to manage it all in the extremest forms can lead to serious problems. But the rapid development is a good thing, I might add, I don't think the software development world has ever moved as fast as it does today, and it's not nearly the end yet as long as more than half of the world's population doesn't have access to the internet and its boundless resources.

I think increasing complexity is just part of software development. I mean look at Facebook and Twitter - they were started using those simple, accessible tools like PHP and Ruby on Rails, which allowed them to get a flying start and adapt quickly to their huge growth (and with the former desperately clinging to their decision, despite lots of people telling them they should use a different technology), but despite that they still turned into some of the most complicated pieces of software ever. The important bit is to be able to manage all that, not so much a decision between a simple or complicated toolset - or having all of your developers know everything. Similarly, the current trend is microservices - again back to simple, one-purpose miniature applications that do one thing and do them right. But those will just end up being the next generation of huge, complicated software systems, given enough time. As a colleague stated, "Microservices are just hipster SOA".

As the saying goes, the more things change, the more they stay the same. The full-stack developer isn't dead and won't be going away any time soon, he'll just go by a different name depending on the times - J2EE Certified Software Engineer, full-stack developer, multidisciplinary expert, T-shaped developer, Xebian, chief of technology evangelisation, or whatever else the HR or marketing departments of the near future will come up with.

Agile Needs to Be Both Iterative and Incremental

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

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

Scrum, like all of the agile processes, is both iterative and incremental. Since these words are used so frequently without definition, let’s define them.

An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas. The team then iteratively refines those areas until the product is satisfactory. With each iteration, the software is improved through the addition of greater detail.

For example, in a first iteration, a search screen might be coded to support only the simplest type of search. The second iteration might add additional search criteria. Finally, a third iteration may add error handling.

A good analogy is sculpting. First, the sculptor selects a stone of the appropriate size. Next, the sculptor carves the general shape from the stone. At this point, one can perhaps distinguish the head and torso, and discern that the finished work will be of a human body rather than a bird. Next, the sculptor refines her work by adding detail. However, the sculptor is unlikely to look on any one area as complete until the entire work is complete.

An incremental process is one in which software is built and delivered in pieces. Each piece, or increment, represents a complete subset of functionality. The increment may be either small or large, perhaps ranging from just a system’s login screen on the small end, to a highly flexible set of data management screens.

Each increment is fully coded and tested, and the common expectation is that the work of an iteration will not need to be revisited. An incremental sculptor would pick one part of her work and focus entirely on it until it’s finished. She may select small increments (first the nose, then the eyes, then the mouth, and so on) or large increments (head, torso, legs and then arms). However, regardless of the increment size, the incremental sculptor would attempt to finish the work of that increment as completely as possible.

Scrum and agile are both incremental and iterative. They are iterative in that they plan for the work of one iteration to be improved upon in subsequent iterations. They are incremental because completed work is delivered throughout the project.

To better illustrate the differences between iterative and incremental, let’s consider building a dating website iteratively but not incrementally. To do this, the team would build a little of every part of the site—profile management, searching, ads, etc. The team would then revisit all parts, improving each.

The team would then revisit all parts again, making further improvements. In this purely iterative way, the entire site is getting a little better.

Next, consider developing the same site with a purely incremental, but not iterative process. If a dating site were built incrementally, the team would build and perfect profile management before starting on any other part of the site. They would then build and perfect a second area, say searching, before moving onto the third area. Each functional area would be made perfect before the next area was started.

Neither iterative nor incremental is all that great alone. But together—as they are with Scrum—they are fantastic.

Agile Needs to Be Both Iterative and Incremental

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

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

Scrum, like all of the agile processes, is both iterative and incremental. Since these words are used so frequently without definition, let’s define them.

An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas. The team then iteratively refines those areas until the product is satisfactory. With each iteration, the software is improved through the addition of greater detail.

For example, in a first iteration, a search screen might be coded to support only the simplest type of search. The second iteration might add additional search criteria. Finally, a third iteration may add error handling.

A good analogy is sculpting. First, the sculptor selects a stone of the appropriate size. Next, the sculptor carves the general shape from the stone. At this point, one can perhaps distinguish the head and torso, and discern that the finished work will be of a human body rather than a bird. Next, the sculptor refines her work by adding detail. However, the sculptor is unlikely to look on any one area as complete until the entire work is complete.

An incremental process is one in which software is built and delivered in pieces. Each piece, or increment, represents a complete subset of functionality. The increment may be either small or large, perhaps ranging from just a system’s login screen on the small end, to a highly flexible set of data management screens.

Each increment is fully coded and tested, and the common expectation is that the work of an iteration will not need to be revisited. An incremental sculptor would pick one part of her work and focus entirely on it until it’s finished. She may select small increments (first the nose, then the eyes, then the mouth, and so on) or large increments (head, torso, legs and then arms). However, regardless of the increment size, the incremental sculptor would attempt to finish the work of that increment as completely as possible.

Scrum and agile are both incremental and iterative. They are iterative in that they plan for the work of one iteration to be improved upon in subsequent iterations. They are incremental because completed work is delivered throughout the project.

To better illustrate the differences between iterative and incremental, let’s consider building a dating website iteratively but not incrementally. To do this, the team would build a little of every part of the site—profile management, searching, ads, etc. The team would then revisit all parts, improving each.

The team would then revisit all parts again, making further improvements. In this purely iterative way, the entire site is getting a little better.

Next, consider developing the same site with a purely incremental, but not iterative process. If a dating site were built incrementally, the team would build and perfect profile management before starting on any other part of the site. They would then build and perfect a second area, say searching, before moving onto the third area. Each functional area would be made perfect before the next area was started.

Neither iterative nor incremental is all that great alone. But together—as they are with Scrum—they are fantastic.

Hyper-connectivity and The Illusion of Progress

3524125987_298260aede_b

I recently attended a meeting and after about ten minutes I was brought up short.  Everyone was paying attention; not one laptop was open nor was anyone reading an email or text under the table.  People were taking notes “old school way”— on paper. The meeting ended on time after 25 minutes, meeting the objective and with the promise of meeting minutes.  I was shocked by the efficiency and effectiveness, and as a result I lingered after the meeting to discuss my observations with my sponsor.

Why is the more typical behavior to be tethered to multiple devices while juggling several projects or tasks? It is more than just a new corporate culture; rather our need for connectedness is based not just on how we see each other, but on how we see ourselves.  Our behavior is grounded in a combination of interlocking facts, self-knowledge and illusion. The keystone illusion that drives this need for hyper-connectedness is the illusion of control. The Illusion of control that we embrace allows us to believe we can script our progress through our career and that we can understand and predict the future like some sort of omnipotent being. In order to build that illusion of control we need build on three basic separate and distinct illusions. Each of these illusions is self-reinforcing.

Returning to my “old school” example, my sponsor indicated that recently meetings at her company were a mirror of many other organizations, lots of hardware and lots of miscommunication. The straw that broke the camel’s back was a senior management session where the CIO was asked the same question twice in less than five minutes.  The CIO levied a $50 fine for an open laptop that is not being used for the projector or the use of a cell during one of his meetings.  Extreme?  Even without the fine, the behavior change filtered through the organization. My sponsor indicated that the meetings had become shorter, as a result, and more effective and happened less frequently.

Passing aside what, without measurement, might be just the party line, why is this an important discussion?  Because once upon a time answering email during a meeting would have been viewed as rude. None of this would make any difference if there weren’t consequences. The whole hyper-connectedness, which has permeated even our most private spaces, causes us to spread our attention, our greatest asset, too thinly. Fractional attention makes you think that we’re progressing; it makes us think that we are important; it makes us think that we can multitask. In reality, fractional attention means that we actually get less done. The three illusions that are required to support the illusion of control are the illusion of progress, the illusion of multitasking and the illusion of importance.  Each of this can be issues in their own right, but together they shape how we behave.

First, the illusion of progress
Focusing on activities such as starting many tasks, participating in many projects or simply texting and answering emails while pretending to listen at a meeting gives an illusion of making progress. The thought is that we can switch in between these activities when we get downtime so that we can perfectly fill our day and be highly effective and efficient.  In reality, we are masking issues by confusing being busy with effective progress.

Second, the illusion of multitasking
In past essays I have dealt with this topic. We don’t multitask; we fast switch. Additionally, lean theory tells us that trying to split our attention between multiple tasks increases the possibility of doing none of them well.  In the work place, true multitasking is rare.  The data shows that generally humans are not really very good at true multitasking in the workplace. Linda Stone noted in the Huffington Post that people tend to stop breathing while they answer email. She even named the malady email apnea. If you need more examples just reflect on the data concerning cell phone usage and driving. Or if data doesn’t work for you, then try writing code while answering emails. Computers, on the other hand, are really good at multitasking and no matter the number of processors we have on our desktop we have not crossed that chasm to become full cyborgs yet . . . or perhaps that will be the outcome of hyper-connectedness.

Last, the illusion of importance
Hyper-connectivity has both positive and negative traits.  It allows us to connect with people and teammates across the globe, a positive except losing a few hours of sleep here or there. Advocates argue that this promotes greater collaboration and facilitates the sharing of ideas.

But it has a darker side in that it can lead us down deep rabbit holes through the implied urgency that each new message creates.  It can also make small issues appear larger and more influential than they really are which again demands our attention.

In a recent talk at Ted, Sherry Turkle stated that hyper-connectivity, with the problems it creates, has become more pervasive than just in a few meetings.

People text or do email during corporate board meetings. They text and shop and go on Facebook during presentations People talk to me about the important new skill of making eye contact while you’re texting.  People explain to me that it’s hard, but that it can be done. Parents text and do email at breakfast and at dinner while their children complain about not having their parents’ full attention. But then these same children deny each other their full attention.

Our electronic tools have been presented to us with the promise of delivering an ability to more closely integrate networks so that tasks, issues, changes, gossip and noise never fall through the cracks.   Content is always available. How many of you sleep with your smart phones next to the bed (or closer) just in case something you need to know happens during the night. Frankly, few of us are that important. However, instant and indiscriminate communication provides an illusion of importance, which reinforces the need to share information as well as to seek it. The act of constant foraging for data makes it difficult to focus on the speaker in a meeting or even responding to an important text message.

 


Categories: Process Management

SPaMCAST 315 – Scrum Masters, Hughson, Form Follows Function

www.spamcast.net

http://www.spamcast.netSPaMCAST

Listen to the podcast.

SPaMCAST 315 features our essay on Scrum Masters.  Scrum Masters are the voice of the process at the team level.  Scrum Masters are a critical member of every Agile team. The team’s need for a Scrum Master is not transitory because they evolve together as a team.

In this edition of the Software Process and Measurement Cast we debut a new column.  Gene Hughson brings the wisdom from his Form Follows Function blog to the SPaMCAST.  Gene appeared on SPaMCAST 268 to talk architecture, people and process.  We are glad to have him back on a regular basis.  This first column discusses the idea that quick fixes might not always be the right answer!

The essay on Scrum Masters begins:

The difference between facilitating and enabling is at the core of the Agile concept of self-organizing and self-managing teams. An effective scrum master should be a facilitator in a well functioning Agile team. However, when there is a breakdown in a self-organizing and self-managing team, sometimes scrum masters become enablers. This makes scrum masters more like project managers. A facilitator helps to unstick something that has stopped or creates an environment where progress can be made by the team.  An enabler provides the team with permission for making a decision.  For example, I recently watched as a team asked their scrum master if they were allowed to hold an interim show and tell/demonstration to prompt the product owner for feedback. The team saw the scrum master as an enabler rather than a facilitator.

Listen to the rest on the Software Process and Measurement Cast!

Call to action!

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.  What will we do with this list?  We have two ideas.  First, we will compile a list and publish it on the blog.  Second, we will use the list to drive “Re-read” Saturday. Re-read Saturday is an exciting new feature that bagan on the Software Process and Measurement blog on November 8th with a re-read of Leading Change. So feel free to choose you platform and send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

SPaMCAST 316 features a return visit from Dr. David Rico.  We talked about the cost of quality and Agile. Does Agile impact the cost of quality?  Dr. Rico walks us through the evidence that not only does Agile improve customer satisfaction but it also improve the cost of quality.  If you are interested in effectiveness, efficiency and quality then this interview for you!

Upcoming Events

DCG Webinars:

How to Split User Stories
Date: November 20th, 2014
Time: 12:30pm EST
Register Now

Agile Risk Management – It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST
Register Now

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.

In this edition of the Software Process and Measurement Cast we debut a new column.  Gene Hughson brings the wisdom from his Form Follows Function blog to the SPaMCAST.  Gene appeared on SPaMCAST 268 to talk architecture, people and process.  We are glad to have him back on a regular basis.  This first column discusses the idea that quick fixes might not always be the right answer!

The essay on Scrum Masters begins:

The difference between facilitating and enabling is at the core of the Agile concept of self-organizing and self-managing teams. An effective scrum master should be a facilitator in a well functioning Agile team. However, when there is a breakdown in a self-organizing and self-managing team, sometimes scrum masters become enablers. This makes scrum masters more like project managers. A facilitator helps to unstick something that has stopped or creates an environment where progress can be made by the team.  An enabler provides the team with permission for making a decision.  For example, I recently watched as a team asked their scrum master if they were allowed to hold an interim show and tell/demonstration to prompt the product owner for feedback. The team saw the scrum master as an enabler rather than a facilitator.

Listen to the rest on the Software Process and Measurement Cast!

Call to action!

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.  What will we do with this list?  We have two ideas.  First, we will compile a list and publish it on the blog.  Second, we will use the list to drive “Re-read” Saturday. Re-read Saturday is an exciting new feature that bagan on the Software Process and Measurement blog on November 8th with a re-read of Leading Change. So feel free to choose you platform and send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

SPaMCAST 316 features a return visit from Dr. David Rico.  We talked about the cost of quality and Agile. Does Agile impact the cost of quality?  Dr. Rico walks us through the evidence that not only does Agile improve customer satisfaction but it also improve the cost of quality.  If you are interested in effectiveness, efficiency and quality then this interview for you!

Upcoming Events

DCG Webinars:

How to Split User Stories
Date: November 20th, 2014
Time: 12:30pm EST
Register Now

Agile Risk Management – It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST
Register Now

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