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!

Feed aggregator

Stop Taking Yourself So Seriously

Making the Complex Simple - John Sonmez - Mon, 06/16/2014 - 15:00

There is a pretty good chance I screwed up today. There is a pretty good chance that this blog article will flop. Maybe, you’ll come here to my blog, expecting to be enlightened, but instead find a bunch of worthless drivel that wasn’t worth the time it took you to read. But, guess what? I […]

The post Stop Taking Yourself So Seriously appeared first on Simple Programmer.

Categories: Programming

How To Assure Your Project Will Fail - UpDate

Herding Cats - Glen Alleman - Mon, 06/16/2014 - 00:19

Screen Shot 2014-05-27 at 1.05.27 PMThere is a short eBook titled Dealing with Complexity in Software Projects that can be downloaded by clicking on the image to the left.

This book starts with the hypothesis put forth by Theory of Project Management: Explanation of Novel Methods, in which it is conjectured that traditional project management processes are now obsolete and new project management processes are needed. Agile of course is one of those suggested. 

This theory is the basis of a product, Last Planner used in the construction business. 

There are some fundamental flaws starting on page 1 of the eBook, where it is asserted Project Management can be divided into main components:

  • Theory of Projects - why are projects important?
  • Theory of Management - how are projects managed?

The first  is nearly universal, projects are the basis of most business processes, other than production and even then, projects are used to establish the production processes. The second part is domain dependent. In the eBook, it is conjectured that the view of projects rests on the assumptions listed in the orginal paper:

  • Tasks are independent, except for their sequential relationships.
  • Tasks are concrete, with start and end dates.
  • There is very little uncertainty regarding requirements and the tasks themselves.
  • All work is possible to capture in a top-down breakdown of the total transformation.
  • All requirements exist at the start and they can be decomposed just like the tasks.

First let's look at these assumptions from a theory testing point of view. If these assumptions are found to be flawed, then what  follows in terms of seeking new ways, may be based on unfounded assertions.

  • Assumption 1: Tasks are Independent
    • Only if the work is not developing a connected and interoperable system made of of other system elements. That is the work is an assembly of parts with no interactions between the parts other than at their interfaces.
    • This is rarely the case in software, hardware, people, or systems-of-systems.
    • This would mean there are only linear connections between the work elements. No merge points or branch points in the sequence of work. 
    • Traditional project management processes deal with these merge and branch points through the technical and programmatic architecture of the project. The network of planned work has many to one and one to many connections throughout the project.
    • Traditional project management processes deal with this quite well, starting with Capabilities Based Planning, moving to Integrated Master Planning, Integrated Master Scheduling, and then the establishment of the risk adjusted Performance Measurement Baseline.
  • Assumption 2: Tasks are Concrete
    • Only if you are pouring concrete or welding pipe, as the original paper suggests projects they are interested in do.
    • If the components of the project being integrated have dynamic behaviours, modern project management methods deal with those through Interface Control Documents, that define both the static and dynamic behaviours of the component. This is the basis of object oriented programming, systems engineering, and most importantly the systems-of-systems approach take by modern project management methods.
    • These interactions are modeled in tools based on sysML. CORE and CRADLE are two I use.
    • The complex behaviours of these interfaces can be modeled. Their dynamic behaviours revealed along with the static - architecture. We use DoDAF as our starting point for architecture. The coupling and cohesion exposed by the tools and the model and most importantly the inter-dependencies documented through another tool - Design Structure Matrix.
  • Assumption 3: There is Very Little Uncertainty
    • This is not only naïve, it is wrong. Or perhaps better stated Pauli's quote, "Das ist nicht nur nicht richtig, es ist nicht einmal falsch!"  - "It is not only not right, it is not even wrong,"
    • All variables on projects are random variables, generated from the underlying statistical processes for cost, schedule, and technical performance.
    • These variables are drawn from two classes of uncertainty.
    • Reducible uncertainty (epistemic) - which can be reduced with time and money to protect the project from their impact.
    • Irreducible uncertainty (aleatory) - which can not be reduced, so margin is need to protect the project from their impact.
    • Modeling this combined uncertainty can start with Monte Carlo Simulation of that non-linear, non-stationary, stochastic network of work activities called the Integrated Master Schedule.
  • Assumption 4: Work can be Captured Top-Down
    • In practice, Capabilities can be defined top down and assessed by Measures of Effectiveness and Measures of Performance.
    • These capabilities reveal the needed requirements in the upcoming capability release plan. This incremental and iterative process is the basis of DOD and NASA programs, so it should be straightforward for complex software projects to apply this as well.
  • Assumption 5: All Requirements Exist At Start - is naïve at best and not factual at worst. These Program Management Handbooks show how to elicit requirements incrementally in an evolutionary manner:
    • Capabilities Based Planning does not assume this
    • DOD 5000.02 does not assume this
    • NASA NPR 7120.5E does not assume
    • You get it, requirements are avaiable up front is a veryt bad assumption.

So Now What?

With the basis for seeking a new and innovative project management process grounded in assumptions that are not actually correct, is there any reason to continue reading the eBook? 

Yes, for one simple reason. To put into perspective the notion of chaos as the basis of any credible probability calculaton for the success of a project. 

Let's review the assumptions that are suggested as the reason to abandon the current project management approach and move to something else.

  • Tasks are Independent — no they're not. They're independent in only the simplest of projects. Dependencies are everywhere. And not just dependencies on logic, but also cost and technical performance. Projects are collections of interdependent networks of non-linear, non-stationary, stochastic processes.
  • Tasks are Concrete — only if you're pouring concrete. Any nontrivial engineering development program has emerging and evolving drivers of cost, schedule, and technology.
  • There is Little Uncertainty - a colleague has a saying the project and its plan is a complex situation adapting to an emerging solution. Behave accordingly.
  • Work Can Be Captured Top Down — this would require clairvoyance and precognition on the parts of the project participants.
  • All Requirements Exist At The Start — same clairvoyance and precognition needed.

Next

These assumptions — wrongly described — are then challanged by the Agile Communities approach.

  • In Agile Software development we assume that requirements are not knowm in full at the start, and we  further assume that they will change during the project.
  • We assume that tasks have some sequence, but that the sequence should follow our beliefs regarding the value of each requirements or tasks, and not a possible work-sequence.
  • We assume that the number of requirements will grow as we understand better the problem space, and that we will find novel ways to execute the initial requirements as we understand better how the software system behaves when in use by actual users.

 Let's start with a framework, well developed in many domans - Capabilities Based Planning. In this framework, we don't start with the requirements. We start with the needed capabilities that will result from the project's outcomes. Let's look at the challanges above in light of Capabilities Based Planning.

Project maturity flow is the incremental delivery of business value from Glen Alleman
  • In Agile Software development we assume that requirements are not knowm in full at the start, and we  further assume that tehy will change during the project.
    • With capabilities, we can develop the needed requirements to implement the capabilities for the release of those capabilities to the production environment.
    • In the above example, Demo Conversion Process, Member Reconciliation is a capabilities that can be put to work.
    • With this capability we can start the next one. Integration of ERP Converted to Inventory
    • The result addressed the emerging requirements issue, by freezing the capabilities long enough to produce a capability that can be put to work and start genertaing the planned value.
    • If the requirements are emerging as we are developing, we'll never reach DONE on the planned day for the planned cost.
  • We assume that tasks have some sequence, but that the sequence should follow our beliefs regarding the value of each requirements or tasks, and not a possible work-sequence.
    • For the needed capabilities to show up on time, for the planned cost and the planned benefits, we will need to have a plan to perform the work in the right order.
  • We assume that the number of requirements will grow as we understand better the problem space, and that we will find novel ways to execute the initial requirements as we understand better how the software system behaves when in use by actual users.
    • The number may grow over time. But during the freeze period needed to produce the planned capabilities, on the planned date, for the planned cost, they had better be stable.
    • Otherwise we have a death march project. One that can never seem to get to DONE, because we keep changing what DONE looks like

The End

Projects have lots of problems - symptoms actually - with root causes. But with the assumptions that are the basis of the paper and the eBook, one primary root cause is simple ...

BAD PROJECT MANAGEMENT

So do we move on to the next project management method before to assess the root causes of the current symptoms, fix the root causes and reassess if the current method has shortcomings? Let's hope not.

Here's the Principles, Practices, and Processes needed to increase the probability of project success. Apply these first, see if they are found wanting for the domain you work in. If so, assess then before abandoning them for others that must first be tested to improve the probability of success before jumping on that band wagon.

Principles and Practices of Performance-Based Project Management® from Glen Alleman So when you hear about the next new thing, do two things.
  • Buy Beyond the Hype: Rediscovering the Essence of Management, Robert G. Eccles and Nitin Nohria, Harvard Business School. Read it and then ask the questions developed in the book to separate hype from Bad Management fixes.
  • Take the contents of the briefing above and see if you can find the Principles, Practices, and Processes on your own project? If not, you may want to install them first before following the pided piper of the next new thing
Related articles Elements of Project Success Positive Deviance The World of Probability and Statistics Statistical Process Control The Basis of All Modern Control Systems Both Aleatory and Epistemic Uncertainty Create Risk
Categories: Project Management

SPaMCAST 294 – Sean Robson, Agile and SAP

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 294! SPaMCAST 294 features our interview with Sean Robson. We discussed his book, Agile SAP: Introducing flexibility, transparency and speed to SAP implementations. SAP and Agile, some say it can’t be done and they would just be wrong.

Sean’s bio reads:
Sean Robson, MBA, PMP, CSM, has been working with SAP software since 1998.  He started as an ABAP Developer then moved into configuring the Enterprise Asset Management module.  From there he transitioned to Business Warehouse and Portal support and later consulting where he worked as team lead, test manager and project manager. A Project Management Professional and Certified ScrumMaster, with wide consulting and industry experience, Sean has managed a variety of SAP project types and sizes. He has worked on projects in several industries throughout North America, including manufacturing, utilities, insurance, health care, aerospace and defense, and the public sector.  He currently works as an SAP Program Manager in the Insurance Industry.

Sean’s contact Information:
Email: sean.p.robson@gmail.com
Blog: http://agilesap.wordpress.com
Buy Sean’s book Agile SAP

Thanks for the feedback on shortening the introduction of the cast this week. Please keep your feedback coming. Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay covering Test Driven Development (TDD). TDD is a development technique that can help teams build the right thing right. Think about it and stop back next week!
Upcoming Events
Upcoming DCG Webinars:
June 19 11:30 EDT – How To Split User Stories
July 24 11:30 EDT – The Impact of Cognitive Bias On Teams
Check these out at www.davidconsultinggroup.com

I will be adding a long list of conferences I will be attending and/or speaking at in the near future.

The first is Agile 2014, July 28 through August 1 in Orlando. Are you going? I look forward to seeing or hearing all SPaMCAST readers and listeners at this great event!

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 294 – Sean Robson, Agile and SAP

Software Process and Measurement Cast - Sun, 06/15/2014 - 22:00

SPaMCAST 294 features our interview with Sean Robson. We discussed his book, Agile SAP: Introducing flexibility, transparency and speed to SAP implementations. SAP and Agile, some say it can’t be done and they would just be wrong.

Sean’s bio reads:
Sean Robson, MBA, PMP, CSM, has been working with SAP software since 1998.  He started as an ABAP Developer then moved into configuring the Enterprise Asset Management module.  From there he transitioned to Business Warehouse and Portal support and later consulting where he worked as team lead, test manager and project manager. A Project Management Professional and Certified ScrumMaster, with wide consulting and industry experience, Sean has managed a variety of SAP project types and sizes. He has worked on projects in several industries throughout North America, including manufacturing, utilities, insurance, health care, aerospace and defense, and the public sector.  He currently works as an SAP Program Manager in the Insurance Industry.

Sean’s contact Information:
Email: sean.p.robson@gmail.com
Blog: http://agilesap.wordpress.com
Buy Sean’s book Agile SAP

Thanks for the feedback on shortening the introduction of the cast this week. Please keep your feedback coming. Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay covering Test Driven Development (TDD). TDD is a development technique that can help teams build the right thing right. Think about it and stop back next week!
Upcoming Events
Upcoming DCG Webinars:
June 19 11:30 EDT – How To Split User Stories
July 24 11:30 EDT - The Impact of Cognitive Bias On Teams
Check these out at www.davidconsultinggroup.com

I will be adding a long list of conferences I will be attending and/or speaking at in the near future.

The first is Agile 2014, July 28 through August 1 in Orlando. Are you going? I look forward to seeing or hearing all SPaMCAST readers and listeners at this great event!

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

Impact Mapping and Integrated Master Planning

Herding Cats - Glen Alleman - Sun, 06/15/2014 - 15:55

Impact MappingIn the literally 1,000's of pieces of correspondence I receive or send monthly, I came in contact with Impact Mapping, Gojko Adzic. At the same time I got an email from a person I met while speaking at last weeks conference (International Cost Estimating and Analysis Association).

This small book has a powerful concept that matches closing with a paradigm used in our domain Integrated Master Plan (IMP) and Integrated Master Schedule (IMS). The IMP/IMS approach to program management starts with a set of Program Events that assess the increasing maturity of the program itself and the deliverables that make up the program.

The IMP is derived through a Systems Engineering process is eliciting the Measures of Effectiveness and Measures of Performance for the outcomes of the program. The things that fly, swim, walk, or drive away after the program is complete. These measures are guided by Key Performance Parameters.

What is of interest is not the IMP/IMS (that's talked about in many other posts) or the book itself (which should be in the shelf of every software and IT Project Manager), but the notion of defining what done looks like in units of measure meaningful to the decision makers

This last phrase of course is the basis of my own book Performance-Based Project Management® which shows how to put that phrase to work.

But that's not the point either. The point is — the notion of defining capabilities connecting these capabilities together to solve a complex problem, eliciting the technical and operational requirements that enable the capabilities to be capable, then collecting all these capabilities and requirements into some model to assess the impacts of each component on the other components to inform the decision makers on the probability of success of the project is actually very rare.

Why is it Rare?

It is rare, because in our technology world we start on the wrong end of the problem. Tom Poppendieck says it best in the forward With few exceptions, software development work has long been separate from other parts of the organizations it supports

This disconnect is not a development problem. It is not a business problem. It is not solved by rapid feedback, since rapid feedback in the absence of a clear and concise description of what DONE looks like in those pesky units of measure meanigful to the decision makers - is just rapid production of software that doesn't solve the real problem. 

The Real Problem

The real problem is neither those paying for the solution nor those providing the solution have a shared understanding of the vision and mission that will drive the needed capabilities before starting work. The notion that the requirements will emerge is used in the agile community. But in fact there is no actual test of that notion. Next week, June 17th, Jim Highsmith is speaking here in Boulder. It'll be interesting to hear what he says about emergence

The real problem is without some shared understanding of mission and vision and the units of effectiveness and perfomance, no project is going to fulfill its goal without waste of time and money. From Joint Strike Fighter to the internal IT project, work without a definitized set of capabilities, simply spends time and money searching from those through rapid delivery of technical outcomes.

It's a solution looking for the problem. Rapidly producing a solution for sure, but looking all the same

So buy the book, it's a good read. And it'll improve the conversation around what DONE looks like. But it's only one piece of the solution to a very complex problem in product development. 

  • What do we want to system to do in the broader business process sense?
  • Do we even have a business process?
  • What are we willing to pay for this system?
  • When do we think we will need this system to provide the capabilities we think we have identified?
  • How can we test the notion of the needed capabilities, the cost, the time to get feedback that we're on the right track for each of those?

The answers to these questions are hard to come by for all the right reasons - they're hard.

So we focus on the things we know about and many times the things that have little to do with the actual problem of producing value in exchange for money.

But buy the Impact Mapping book, buy my book, buy a Balanced Scorecard books and read articles, buy a strategy making book. Start with the hard part first - what does DONE look like.

One Small Glitch

On page 27 of Impact Mapping is a topic of adaptive planning. Adapting your plans to emerging situations is called planning. Plans are meant to reveal the future and therefore must be changed when encountering the reality of the situation.

The picture used is of a person building a Dog House, then bringing a dog to the Dog House and realizing the Dog House is too small. Then having an ideas for a larger Dog House.

This is bad project management and bad planning. If you are going to build a Dog House, you'd better figure out what size dog will fit in the Dog House before starting to hammer. If you have a dog and build the Dog House too small, you're a poor engineer. If you build the Dog House before knowing what size dog will fit in the Dog House, you're a bad planner. 

DDSTOP

Other than that the Impact Mapping book is a must read. 

Related articles

The "Real" Root Cause of IT Project Failure 5 Questions That Need Answers for Project Success How To Assure Your Project Will Fail Why Agile is failing
Categories: Project Management

Splitting User Stories Using Multiple Patterns

Sometimes you need several options.

Sometimes you need several options.

Smaller stories generally encourage throughput and are better for team productivity. Patterns provide help for teams as they groom and split stories.  There are numerous patterns that can be used. For example: elementary processes, data variations, business rules and workflow. All of these patterns are useful, BUT there is no single pattern that works all of the time. Using patterns in combination often provides better results.

For example in Splitting User Stories Based on Elementary Processes, one of the stories that we generated was:

As a time accounting user, I want to add my time to my timecard so I can account for the work I do.

Could we break this story down further?  Leveraging the workflow pattern we would find that there are two possible workflows 1) adding time to an existing card, and 2) adding time to a new card.  We described the workflow to establish a new time card in Splitting User Stories Using Workflows.  

 Untitled

Comparing the workflow immediately confirms that the two flows are different and could be split.  Adding a review of the workflow after splitting stories using the elementary process provides a team with options to split the larger user story about adding time to a timecard.  Whether the team splits the stories depends on the capability and productivity/velocity of the team.  

One pattern for splitting user stories is not necessarily better than another.  When left to my own devices I tend to favor workflow patterns (I draw lots of process maps).  Adding a second or third pattern provides teams with a chancing to identify nuances and to break stories down into more granular slices.  Recognize that as teams break stories down they are filling in holes in the requirements and their understanding of the product they will deliver.  Splitting stories increases the throughput of work, the productivity/velocity of the group and the completeness of the solution. 


Categories: Process Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 06/14/2014 - 16:37

It is remarkable that a science which began with the consideration of games of chance should become the most important object of human knowledge — Pierre Simom Laplace, 1812.

The notion that all project variables are Random Variables is not well understood in many instances, especially in the agile community and those suggesting that estimating cost, schedule, and performance are not needed to make business decisions.

In some agile paradigms, fixed duration sprints mortgage the future by pushing unfinished or un-started features to future sprints resulting in a Minimal Viable Features outcome rather than the Needed Capabilities for the business case or mission success.

While possibly useful in some domains, many domains assume the minimum features are the same as the required features. Without all the required features, the system is non-functional. Management Reserve, schedule margin, and cost margin are needed to proetct those required features, their cost and their schedule from the random behaviours shown below.

Screen Shot 2014-06-14 at 8.35.49 AM

When developing products or services using other peoples money, it is incumbent on us to have some understanding of how these random variables behave on their own and interact with each other. This knowledge provides the basis for making decisions about how that money will result in value to those providing the money. In the absence of that knowledge, those providing the money have no way of knowing when the project will complete, how much it will cost when it is complete, and what the probability is of the capabilities produced by the project to meet the needed business, technical, or mission goals. And most importantly how to make decisions based on those behaviours and interactions. They are deciding without the needed information of the consequences of their decisions. 

To continue to assume otherwise ignores Laplaces.

Related articles Four Critical Elements of Project Success How To Assure Your Project Will Fail Making Estimates For Your Project Require Discipline, Skill, and Experience Software Cost Estimating Information Can There Be Successful Projects With Fixed Dates, Fixed Budgets, and Promised Minimal Features?
Categories: Project Management

Combining Salt with Docker

Xebia Blog - Sat, 06/14/2014 - 10:59

You could use Salt to build and run Docker containers but that is not how I use it here. This blogpost is about Docker containers that run Salt minions, which is just an experiment. The use case? Suppose you have several containers that run a particular piece of middleware, and this piece of middleware needs a security update, i.e. an OpenSSL hotfix. It is necessary to perform the update immediately.

 

The Dockerfile

In order to build a container you have to write down the container description in a file called Dockerfile. Here is the Dockerfile:

#-------
# Standard heading stuff

FROM centos
MAINTAINER No Reply noreply@xebia.com

# Do Salt install stuff and squeeze in a master.conf snippet that tells the minion
# to contact the master specified.

RUN rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm
RUN yum install -y salt-minion --enablerepo=epel-testing
RUN [ ! -d /etc/salt/minion.d ] && mkdir /etc/salt/minion.d
ADD ./master.conf /etc/salt/minion.d/master.conf

# Run the Salt Minion and do not detach from the terminal.
# This is important because the Docker container will exit whenever
# the CMD process exits.

CMD /usr/bin/salt-minion
#-------

 

Build the image

Time to run the Dockerfile through docker. The command is:

$ docker build --rm=true -t salt-minion .

provided that you run this command in the directory where file Dockerfile and master.conf resides. Docker creates an image with tag ‘salt-minion’ and throws away all intermediate images after a successful build.

 

Run a container

The command is:

$ docker run -d salt-minion

and Docker returns:

aab154310ba6452ba2c686d15b1e3ca5fd85124d38c7935f1200d33b3a3e7ced

The Salt minion on the container is started and searches for a Salt master to connect to, defined by the configuration setting “master” in file /etc/salt/minion.d/master.conf. You might want to run the Salt master in “auto_accept” mode so that minion keys are accepted automatically. Docker assigns a container id to the running container. That is the magic key that docker reports as a result of the run command.

The following command shows the running container:

$ docker ps
CONTAINER ID        IMAGE                COMMAND                CREATED             STATUS              NAMES
273a6b77a8fa        salt-minion:latest   /bin/sh -c /etc/rc.l   3 seconds ago       Up 3 seconds        distracted_lumiere

 

Apply the hot fix
There you are: the Salt minion is controlled by your Salt master. Provided that you have a state module that contains the OpenSSL hot fix, you can now easily update all docker nodes to include the hotfix:

salt \* state.sls openssl-hotfix

That is all there is to it.

Setting up the hostname in Ubuntu

Agile Testing - Grig Gheorghiu - Fri, 06/13/2014 - 23:04
Most people recommend setting up the hostname on a Linux box so that:

1) running 'hostname' returns the short name (i.e. myhost)
2) running 'hostname -f' returns the FQDN (i.e. myhost.prod.example.com)
3) running 'hostname -d' returns the domain name (i.e prod.example.com)

After experimenting a bit and also finding this helpful Server Fault post, here's what we did to achieve this (we did it via Chef recipes, but it amounts to the same thing):

  • make sure we have the short name in /etc/hostname:
myhost

(also run 'hostname myhost' at the command line)
  • make sure we have the FQDN as the first entry associated with the IP of the server in /etc/hosts:
10.0.1.10 myhost.prod.example.com myhost myhost.prod
  • make sure we have the domain name set up as the search domain in /etc/resolv.conf:
search prod.example.com

Reboot the box when you're done to make sure all of this survives reboots.


Splitting User Stories Based on Elementary Processes

User stories are split like wires.

User stories are split like wires.

Thinly slicing functionality by splitting user stories helps teams to focus their activity on quickly delivering work that is meaningful to the user. Another pattern useful for splitting user stories is the concept of the elementary process defined by the International Function Point User Group (IFPUG) as the “smallest unit of activity that is meaningful to the user”.

The process of splitting user stories into elementary processes can be paraphrased by three criteria that can be easily applied. The criteria are:

  1. Is the story meaningful to the user?
  2. Does the story represent a single, functionally useful element?
  3. Is the story self-contained (independent)?

Note:  As a Certified Function Point Specialist, I am aware that this is a simplification of the process used in IFPUG Function Point Counting to identify elementary processes.  The goal of using the elementary process logic is to provide a framework/pattern for breaking large user stories into more manageable chunks, not to preprocess the stories to make function point counting a rote process.

Leveraging the time accounting example I began in Splitting User Stories by Workflow, a large user story (also known as an epic) for logging and maintaining time accounting data could be written as:

As a time accounting user, I want to maintain my time so that I can account for the work I do.

Anyone that has ever had to use a time accounting system can relate to this story.  The word ‘maintained’ typically has special meaning to anyone that has counting function points. By general convention the word maintain(ed) means adding, changing, deleting and displaying.  These are four separate business functions.  Applying our elementary process criteria to the large story.

Untitled

Based on the application on the elementary process pattern this user story would need to be split.  If we break the story into four separate stories (after a conversation with the product owner) the new stories would be:

  1. As a time accounting user, I want to add my time to my time card so I can account for the work I do.
  2. As a time accounting user, I want to display the time I entered so I can ensure I entered my time correctly.
  3. As a time accounting user, I want to change the time I previously entered so I can fix my mistakes.
  4. As a time accounting user, I want to delete time I entered in case I enter the wrong week or day.

Applying the simplified elementary process criteria:


Untitled2

Splitting the large story based on the elementary process pattern generates more four granular stories. The elementary process pattern yields user stories that also fit INVEST criteria that has been found useful to judging user stories.


Categories: Process Management

Splitting User Stories Based on Data Variations

One wheel or two, there will be a data variation.

One wheel or two, there will be a data variation.

User stories represent a change in approach from capturing and documenting requirements at the beginning of the project in a classic requirement document. Those requirements whether written in prose style or in use cases are then put under close control using techniques like change control boards.  In Agile techniques like user stories are used to capture user intent knowing that in order to deliver functionality conversation and feedback will be required. Every story is different and will require more or less work to express.  Perhaps to abuse the metaphor of a story, consider the production of a novel, in general the longer the novel the more effort that will be required to write it and the longer the author will have to wait for feedback. Shorter stories can generally be delivered faster, meaning that you can get feedback faster.  This one of the reasons we split user stories.  

There are many patterns to help teams split stories into more granular increments, that are also complete deliverables, and meet the INVEST criteria. Data variations is one such pattern.  Data variations occur when there are nuances in the groups of data needed to describe an object or an entity (for example, retail customers and wholesale customers are similar, but probably have some data differences).  The differences between the different kinds of customers represent an opportunity for splitting the stories that impact customers.

We going to build on the time accounting example from earlier this week. We noted that a contract employee could not approve a time sheet, while certain types of employees could approve time sheets.  This business rule could lead to a difference in data structure for contract employees vis-à-vis regular employees (note: this is not to suggest that there might not be other differences in the data structure).  Based on the data structure difference the user story, “As a business owner, I want time entered to be approved by an employee to avoid the perception of conflict of interest” could be split based data structure variations as follows:

As a business owner, I do not want contract employees to be able to approve time sheets to avoid conflict of interest.

As a business owner, I want time sheets to be approved to ensure proper billing.  

A less nuanced example of data variation is an extended family.  A simple entity relationship diagram (ERD) of a family suggests several different groups of data.

 Untitled

If we were writing stories based on variations in data, using the model (above) we would expect stories related to individuals, roles, relationships and family. 

Many data variations are driven either by workflow or business rules, therefore splitting by data variations can be feel very similar to splitting other techniques.  Using data variances to suggest how to split user stories provides Agile teams with another tool to groom user stories. Having a pallet of different techniques will help a team stay effective regardless of project type or business situation. 


Categories: Process Management

Experimenting with Better Workshops

NOOP.NL - Jurgen Appelo - Thu, 06/12/2014 - 17:43
Workshop Experiments

The first two workshops were a bit scary! (Well, for me they were.) As a facilitator, I’m trying many things for the first time. Some things work, some things don’t. That’s a good thing. The idea of exploration is, when half of the experiments fail, you’re learning as fast as possible.

The post Experimenting with Better Workshops appeared first on NOOP.NL.

Categories: Project Management

Simplicity is the Ultimate Enabler

“Everything should be made as simple as possible, but not simpler.” – Albert Einstein

Simplicity is among the ultimate of pursuits.  It’s one of your most efficient and effective tools in your toolbox.  I used simplicity as the basis for my personal results system, Agile Results, and it’s served me well for more than a decade.

And yet, simplicity still isn’t treated as a first-class citizen.

It’s almost always considered as an afterthought.  And, by then, it’s too little, too late.

In the book, Simple Architectures for Complex Enterprises (Developer Best Practices), Roger Sessions shares his insights on how simplicity is the ultimate enabler to solving the myriad of problems that complexity creates.

Complex Problems Do Not Require Complex Solutions

Simplicity is the only thing that actually works.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“So yes, the problems are complex.  But complex problems do not ipso facto require complex solutions.  Au contraire!  The basic premise of this book is that simple solutions are the only solutions to complex problems that work.  The complex solutions are simply too complex.”

Simplicity is the Antidote to Complexity

It sounds obvious but it’s true.  You can’t solve a problem with the same complexity that got you there in the first place.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“The antidote to complexity is simplicity.  Replace complexity with simplicity and the battle is three-quarters over.  Of course, replacing complexity with simplicity is not necessarily simple.” 

Focus on Simplicity as a Core Value

If you want to achieve simplicity, you first have to explicitly focus on it as a core value.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“The first thing you need to do to achieve simplicity is focus on simplicity as a core value.  We all discuss the importance of agility, security, performance, and reliability of IT systems as if they are the most important of all requirements.  We need to hold simplicity to as high a standard as we hold these other features.  We need to understand what makes architectures simple with as much critical reasoning as we use to understand what makes architectures secure, fast, or reliable.  In fact, I argue that simplicity is not merely the equal of these other characteristics; it is superior to all of them.  It is, in many ways, the ultimate enabler.”

A Security Example

Complex systems work against security.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“Take security for example.  Simple systems that lack security can be made secure.  Complex systems that appear to be secure usually aren't.  And complex systems that aren't secure are virtually impossible to make either simple or secure.”

An Agility Example

Complexity works against agility, and agility is the key to lasting solutions.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“Consider agility.  Simple systems, with their well-defined and minimal interactions, can be put together in new ways that were never considered when these systems were first created.  Complex systems can never used in an agile wayThey are simply too complex.  And, of course, retrospectively making them simple is almost impossible.”

Nobody Ever Considers Simplicity as a Critical Feature

And that’s the problem.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“Yet, despite the importance of simplicity as a core system requirement, simplicity is almost never considered in architectural planning, development, or reviews.  I recently finished a number of speaking engagements.  I spoke to more than 100 enterprise architects, CIOs, and CTOs spanning many organizations and countries.  In each presentation, I asked if anybody in the audience had ever considered simplicity as a critical architectural feature for any projects on which they had participated. Not one person had. Ever.”

The Quest for Simplicity is Never Over

Simplicity is a quest.  And the quest is never over.  Simplicity is a ongoing pursuit and it’s a dynamic one.  It’s not a one time event, and it’s not static.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“The quest for simplicity is never over.  Even systems that are designed from the beginning with simplicity in mind (rare systems, indeed!) will find themselves under a never-ending attack. A quick tweak for performance here, a quick tweak for interoperability there, and before you know it, a system that was beautifully simple two years ago has deteriorated into a mass of incomprehensibility.”

Simplicity is your ultimate sword for hacking your way through complexity … in work … in life … in systems … and ecosystems.

Wield it wisely.

You Might Also Like

10 Ways to Make Information More Useful

Reduce Complexity, Cost, and Time

Simple Enterprise Strategy

Categories: Architecture, Programming

Software Development Linkopedia June 2014

From the Editor of Methods & Tools - Thu, 06/12/2014 - 17:08
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 project estimation, JavaScript frontend testing and refactoring, retrospectives, software configuration, Test-Driven Development, software tools and NoSQL databases. Blog: Calculating Velocity FAQ Blog: Writing Testable Frontend Javascript Part 1 – Anti-patterns and their fixes Blog: Writing Testable Frontend Javascript Part 2 – Refactor away anti-patterns Blog: Creating options by slicing features – #NoEstimates technique Article: Agile Retrospectives: Why They Matter Article: First Sketches of an App: Planning the Design ...

Start exploring I/O 2014 with the new and improved Android mobile app

Google Code Blog - Thu, 06/12/2014 - 17:00

By Mónica Bagagem, Developer Marketing and Bruno Oliveira, Developer Relations

We’re pleased to announce the Google I/O 2014 app is now available on Google Play!


We designed the app to be your co-pilot to navigate the conference and make the best of I/O 2014, whether you’re attending in-person or remotely. This means you’ll be able to explore the full conference agenda, add events to a personalized schedule, find your next session on the map and enjoy facilitated pre-event WiFi configuration for those of you who will be joining us at Moscone.  blog-post-image-1.png blog-post-image-2.png  But the list goes on! Here is a rundown of the main features, with even more to come closer to I/O:


  • Find relevant content faster: Browse the full conference agenda and build your personalized schedule. With new filters for theme, topic and type of event, it's easy to find the content you want. Don't know what you are looking for? No problem! During the conference, the “Explore” screen always shows you what is happening right now and what's coming up, so you can decide where to go next. Plus, your schedule is kept in sync between your Android devices and the I/O website.
  • Relive past I/Os: Watch videos from previous years in the “Video Library”, organized by year and topic. Sit back and catch up on those great talks as you refresh your skills and prepare for I/O 2014!
  • Get reminded when and where it matters: The app will send you reminders when your sessions are about to begin, and once sessions end to provide feedback. You can also enable Google Calendar integration (in the app Settings) so you can see your I/O and personal events all in one place across your devices.
  • Enjoy I/O from anywhere: If you’re attending I/O remotely, you can enjoy live streamed content with closed captions directly from your device.
  • Take advantage of extra screen space: When designing the app, we dedicated a lot of time thinking through how to design for different screen sizes, from phone to tablet. The result is a beautiful and optimized experience across Android devices.
blog-post-image-3.png In addition to being useful to conference attendees, the I/O app serves as a real-life example of best practices for Android app development, and will be open-sourced shortly. Stay tuned!

We hope you are as excited as we are about this year’s conference! So have some fun exploring the things I/O 2014 has to offer, starting today - download the app here.
Mónica Bagagem is part of the Developer Marketing team, working on Google I/O and supporting Designer related efforts. She is a world traveler and a brunch lover.

Bruno Oliveira is a member of the Developer Relations team and is the Tech Lead for the Google I/O 2014 app. He is a geek who enjoys code, photography, sci-fi and old games with big pixels and square waves.
Categories: Programming

Switching My Videos to Once a Month

Making the Complex Simple - John Sonmez - Thu, 06/12/2014 - 15:00

I’ve decided to start cutting back on some of the work I am doing each week. I want to have more time to do other things and I don’t feel that I am able to offer as much value when I am only producing content and not doing other things. This video explains it all.

The post Switching My Videos to Once a Month appeared first on Simple Programmer.

Categories: Programming

An Exercise in Documenting Current State: Reddit and the Decision Tree

Software Requirements Blog - Seilevel.com - Thu, 06/12/2014 - 12:27
An exercise in documenting current state: reddit and the decision tree In an earlier post I detailed how you can use RML models to document the current state of your systems and processes by using a Business Data Diagram to illustrate the hierarchy and relationship of objects on the popular content website Reddit.com. In this […]
Categories: Requirements

Creating options by slicing features - #NoEstimates technique

Software Development Today - Vasco Duarte - Thu, 06/12/2014 - 04:00

Each feature (or story) in a product backlog contains many undiscovered options. By taking features as they are without slicing them into thin slices of functionality we implicitly commit to an implementation strategy. However, when we slice features we create options that allow us to pro-actively manage the scope of a project.

Let’s return to the IT Support Ticketing System project we discussed in a previous post. A feature like the one below will not allow us to manage the scope actively.

  • As an employee I want to be able to submit issues to IT so that I can fix a particular problem that prevents me from working.

The feature above is what I would call a “binary” feature. Either the employee is able to submit an issue to IT or not. This simple feature can have large implications in terms of the amount of work required to implement it. Taking the feature above and breaking it down into several smaller features or stories will allow us to make decisions regarding the implementation order, or delaying certain parts of the implementation. Let’s look at an example:

  • As an employee I want to be able to email an IT issue to the IT department so that I can have a fix for a problem that prevents me from working As an IT helpdesk employee I want to have a queue of issues to handle so that I know what items I should be working on at any given time.

By slicing the original feature in this particular way we unpacked the functionality under the term “submit issues” in the original feature into two different features: Email (replaces submit) and Queue of issues (replaces the receiving end of the submission process). We’ve potentially reduced the scope of the initial feature (no need to have a system to enter IT tickets, just send an email), and we’ve given ourselves the option to implement a solution based on standard tools. The two features we created allow for a solution based on email and a spreadsheet program with shared editing, like Google Docs.

These two stories could still be implemented with a full-fledged IT issue tracking system, but that is an option. Not a mandatory outcome of the initial feature. Slicing features into separate functional parts helps us actively manage the scope by creating different implementation options that are often implicit and non-negotiable when we have larger features in the backlog.

Picture credit: John Hammink, follow him on twitter

Splitting User Stories Based on Business Rules

Business rules are a set of statements that indicate whether or not something can be done or provide criteria and conditions for making decisions.

Business rules are a set of statements that indicate whether or not something can be done or provide criteria and conditions for making decisions.

Splitting users stories can have a significant impact on how teams behave, and to an extent, the performance the team.  For example, the granularity of user story splits could lead a team to accept or not accept a specific story into a sprint, and if a large story is taken into a sprint it might not be completed causing the team to fail to reach the commitment they have made, thereby reducing motivation and productivity.  Splitting stories is not a trivial exercise.  Patterns application and user behavior are tools to help teams decide how to split user stories.  Business rules are a type of pattern than can be used to split user stories. Business rules are a set of statements that indicate whether or not something can be done or provide criteria and conditions for making decisions (from BRCommunity.com).

Using the time accounting application from Splitting User Stories by Workflow, we defined a large user story for logging time as:

  1. As a time accounting user, I want to log into the time accounting system securely so that I can log my time.
  2. As a project manager, I want to be able to review and approve time and expenses logged to my projects to ensure accurate reporting and billing.

There are several business rules that govern time accounting. An example of the business rules are governing the number hours that can be booked in a week:

  1. Employees must log at least 40 hours of work per week.
  2. Contractors may log less than 40 hours of work per week.

Applying splits based on the business rule examples for the number of hours booked would yield two potential stories. 

  1. As a business owner, I want employees to account for a full week’s work of at least 40 hours so that I can ensure all employees are busy delivering value.
  2. As a business owner, I want contractors only to enter the time they work so that I do not overcharge clients.

The first story is the most general and the second is more constrained, which suggests some dependence between the two stories. Either could be developed first, although it might be easier to go from general to specific logically.

A second set of of business rules governing who can approve the time entered include:

  1. Time entered for a specific project must be approved by the project’s project manager.
  2. An employee manager must approve time entered by contractors for payment.
  3. Executive managers can approve time when project managers are on short-term leave or vacation.

Restating each of the three rules as user stories would yield:

  1. As a project manager, I want to be able to review and approve time and expenses logged to my projects to ensure accurate reporting and billing.
  2. As a business owner, I only want employee managers to approve time entered by contractors to avoid the appearance of impropriety.
  3. As a business owner, I want to ensure that time can be approved when project managers are on short-term leave or vacation so that billing is not affected.

In all cases we would have to apply the INVEST criteria to determine whether the splits made were granular enough for the team.  Business rules provide team members with a framework for splitting user stories.  Just like splitting based on workflow, business rules as a pattern is just a different way at looking at a set of requirements.  


Categories: Process Management

Read a Book! Or Two.

NOOP.NL - Jurgen Appelo - Wed, 06/11/2014 - 15:08
Read a Book

I started running. Again.

But unlike previous (failed) attempts, this time, I want to do it right. This time, I intend to learn. That’s why I recently read The Power of Habit, by Charles Duhigg. Instead of just going for a run whenever I feel in the mood (which is almost never), I wanted to understand how to really make running part of my daily habits. Thanks to the book, I understand what to do now. My next challenge is to look for inspiration on why to keep running, which is the reason I’m reading Eat and Run. The next book on my list is the brilliantly titled Never Wipe Your Ass with a Squirrel.

The post Read a Book! Or Two. appeared first on NOOP.NL.

Categories: Project Management