Skip to content

Feed aggregator

What is DevOps, Anyway?

Agile Management Blog - VersionOne - Wed, 10/29/2014 - 20:04

We just got done moderating the latest webinar in the AgileLIVE series… “The Challenges and Rewards of DevOps.” The series started last week with Damon Poole, chief agilist at Eliassen Group. Damon did a really good deep-dive into What is DevOps? and we wrapped up today in Part 2 with Andy Powell and Ian Culling of VersionOne.

Here are some of the comments in my notes:

  • DevOps is inextricably linked to Continuous Deployment/Delivery/Everything.
  • DevOps automates and accelerates the build-test-deploy infrastructure.
  • DevOps reinforces that “working software in customers’ hands is the measure of DONE, not features that made it into the release.”
  • DevOps is a goal. You can’t just leap into it. It requires trust, people working closely together.
  • Ops often hears: “’Those dev cowboys’ want to deploy every minute of every day.” Ops is here to make sure nothing breaks in production. DevOps aligns ‘em.
  • For DevOps to work, it is critical to have really good collaboration and trust between development and operations teams.

But the most interesting comment I heard came over the Q&A panel from an attendee:

“Is DevOps infecting Dev people with Ops thinking, or is it the other way around?”

What do you think? Whether you are already rolling with DevOps at your organization, or just trying to learn  what is DevOps… we’d like to hear your opinions.  If you want a copy of the recordings for AgileLIVE: The Challenges and Rewards of DevOps, simply post a comment here and we’ll send them.

Categories: Companies

Spark the Change Toronto – Pre-Registration Started

Learn more about our Scrum and Agile training sessions on

This looks like a great conference – to be held on Thursday, April 23rd, 2015.  From the description:

An event for the whole organization, Spark brings together leaders from across the business to explore how they can work together to create lasting and total change. Talks and workshops offer inspiring examples and practical advice on taking action and overcoming obstacles. – See more at:

Sign up for pre-registration for Spark the Change Toronto

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Reflections on Design Patterns After Two Decades

NetObjectives - Wed, 10/29/2014 - 19:08
On the 20th Anniversary of Design Patterns, the InformIT editorial team decided to ask several patterns gurus for their reflection on patterns over the last two decades.  You can see the entire article here. Here's Jim Trott and my post - Design Patterns in an Agile World After two decades of use, design patterns are as misunderstood as they were when they were first introduced. They are...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

The Magic and Science of Teams

Notes from a Tool User - Mark Levison - Wed, 10/29/2014 - 17:02

While in Florida for Agile 2014, Mark was interviewed by InfoQ about “The Magic and Science of Teams”.

Mark Levison on the Magic and Science of Teams
Mark explains that there are some exciting things happening as years of research in basic studies of teams in organizations combines with behavioural psychology and neuroscience, and recent access to large data sets. This all creates a science that can be applied to help develop high performance teams, which is Mark’s specialty.

You can access the full video with transcript of “Mark Levison on the Magic and Science of Teams” here.

Certified Scrum Trainer Mark Levison offers insight into the neuroscience of teams with five proven Agile methods to create teams that sizzle not fizzle. Get a FREE copy of Five Steps Towards Creating High-Performance Teams when it is published and put your team on the path to high-performance success.

Register to get a
FREE advance copy of
5 Steps Towards Creating High-Performance Teams * indicates required Email Address *

First Name *

Last Name *

Categories: Blogs

Azure Mobile Services with AutoMapper

Jimmy Bogard - Wed, 10/29/2014 - 15:23

At the recent Xamarin Evolve conference, Paul Batum gave a great talk on Azure Mobile Service in cross-platform business apps, part of which included a piece on how AutoMapper fits in with their overall system:

There were sooooo many of those C# shirts at the conference, I felt a little left out without one.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

How to Dockerize your Dropwizard Application

Xebia Blog - Wed, 10/29/2014 - 11:47

If you want to deploy your Dropwizard Application on a Docker server, you can Dockerize your Dropwizard Application. Since a Dropwizard Application is already packaged as an executable Java ARchive file, creating a Docker image for such an application should be easy.


In this blog, you will learn how to Dockerize a Dropwizard Application using 4 easy steps.

Before you start

  • You are going to use the Dropwizard-example application, which can be found at the Dropwizard GitHub repository.
  • Additionally you need Docker. I used Boot2Docker to run the Dockerized Dropwizard Application on my laptop. If you use boot2Docker, you may need this Boot2Docker workaround to access your Dockerized Dropwizard application.
  • This blog does not describe how to create Dropwizard applications. The Dropwizard getting started guide provides an excellent starting point if you like to know more about building your own Dropwizard applications.


Step 1: create a Dockerfile

You can start with creating a Dockerfile. Docker can automatically build images by reading the instructions described in this file. Your Dockerfile could look like this:

FROM dockerfile/java:openjdk-7-jdk

ADD dropwizard-example-1.0.0.jar /data/dropwizard-example-1.0.0.jar

ADD example.keystore /data/example.keystore

ADD example.yml /data/example.yml

RUN java -jar dropwizard-example-1.0.0.jar db migrate /data/example.yml

CMD java -jar dropwizard-example-1.0.0.jar server /data/example.yml



The Dropwizard Application needs a Java Runtime, so you can start from an base image already available at Docker Hub, for example: dockerfile/java:openjdk-7-jdk.

You must add the Dropwizard Application files to the image, using the ADD instruction in your Dockerfile.

Next, simply specify the commands of your Dropwizard Application, which you want to execute during image build and container runtime. In the example above, the db migrate command is executed when the Docker image is build and the server command is executed when you issue a Docker run command to create a running container.

Finally, the EXPOSE instruction tells Docker that your container will listen on the specified port(s) at runtime.


Step 2: build the Docker image

Place the Dockerfile and your application files in a directory and execute the Docker build command to build an Docker image.

docker@boot2docker:~$ docker build -t dropwizard/dropwizard-example ~/dropwizard/


In the console output you should be able to that the Dropwizard Application db migrate command is executed. If everything is ok, the last line reported informs you that the image is successfully build.

Successfully built dd547483b57b


Step 3: run the Docker image

Use the Docker run command to create a container based on the image you have created. If you need to find your image id use the Docker images command to list your images. It should take around 3 seconds to start the Dockerized Dropwizard example application.

Docker run –p 8080:8080 dd547483b57b

Notice that I included the –p option to include a network port binding, which maps 8080 inside the container to port 8080 on the Docker host.  You can verify whether your container is running using the docker ps command.

docker@boot2docker:~$ docker ps

CONTAINER ID        IMAGE                                  COMMAND                CREATED             STATUS              PORTS                    NAMES

3b6fb75adad6        dropwizard/dropwizard-example:latest   "/bin/sh -c 'java -j   3 minutes ago       Up 3 minutes>8080/tcp   high_turing


  1. Test the application

Now the application is ready for use. You can access the application using your Docker host ip address and the forward port 8080. For example, use the Google Advanced Rest Client App to register “John Doe”.


Categories: Companies

The Tyranny of the Ever Decreasing Timebox

Agile software development methods, with the exception of Feature-Driven Development, adopt the use of fixed time increments, often wrongly called “iterations”. In Scrum, these are known as Sprints. A Sprint is a fixed period of time with a defined scope and a commitment to complete that scope within that time window. Originally, Scrum defined 4 week sprints. This was changed later, circa 2004, to a recommendation for 2 weeks to be the default length for a sprint. In general it is recognized that agility is related to the frequency of interaction with the customers or business owners, and the frequency of deliveries. Hence, smaller timeboxes are more desirable. Software quality is often related to batch size and time to complete work in a non-linear fashion, hence, smaller batches, completed in short periods of time leads to dramatically fewer defects.

As a result of all these advantages, organizations adopting Agile software development methods, have been under pressure to adopt the use of shorter and shorter timeboxes for their sprints or iterations. On the face of it, smaller timeboxes and hence smaller batch sizes for the sprint backlog, are a good thing. However, smaller timeboxes create two types of pressure that are often difficult to cope with and adjust to: firstly, smaller batches require an ever more detailed approach to requirements analysis and development – the need to write every more fine-grained stories which can be completed within the smaller time window; and the need for an ever more accurate approach to estimation, so that a realistic commitment can made.

read more

Categories: Companies

Scrum “Inputs”

Learn more about our Scrum and Agile training sessions on

The Product Backlog is often described as the primary input to Scrum.  The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog.  In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog.  And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role.  I believe in just starting if you can.  I even wrote a blog post about this a while back and I stand by it.

I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing.  Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start.  And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.

The Scrum Guide recognizes the following inputs to Sprint Planning:

  • Product Backlog
  • Latest product increment (not applicable to first Sprint)
  • Projected capacity of the Development Team during the Sprint
  • Past performance of the Development Team (not applicable to first Sprint)
  • Definition of “Done” (implicitly)

A newly-formed team often needs to address the following before the first Sprint:

  • Product Backlog
  • Projected capacity of the Development Team during the Sprint
  • Definition of “Done”

If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).

Product Backlog

Keep it simple.  It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product.  Get the Product Owner to blow these things out into a list.  It doesn’t need to be a complete list.  Just the most important things right now.  A good test is to give the Product Owner 5 minutes.  Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on.  There are all kinds of techniques that can be used to order the Product Backlog.  The simplest way is to just have the Product Owner eyeball it.  If people are uncomfortable with this, then introduce the other ways.  It doesn’t need to be perfect.  It will get better and become refined and adapted as you go.

Projected capacity of the Development Team during the Sprint

Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%).  If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post.  According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).

Definition of “Done”

This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done.  The team needs to know this before it can estimate the items in the Product Backlog as a team.  Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.

Planning with the Product Backlog, projected capacity and Definition of “Done”

In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”.  Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done.  All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built.  The team should try to create a set of tasks each of which are a one-person day effort or less.  Count the number of tasks.  If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog.  If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Comparing processing times of NServiceBus saga patterns

Jimmy Bogard - Tue, 10/28/2014 - 19:16

A few weeks ago I gave a talk at NSBCon NYC on scaling NServiceBus, and one of the pieces I highlighted were various saga/processing patterns and how they can affect performance. It was difficult to give real numbers as part of the discussion, mostly because how long it takes to do something is highly variable in the work being done and environmental constraints.

I compared three styles of performing a set of distributed work:

And highlighted the performance differences between them all. Andreas from the Particular team mentioned that some work had been done to improve saga performance, so I wanted to revisit my assumptions to see if the performance numbers still hold.

I wanted to look at a lot of messages – say, 10K, and measure two things:

  • How long it took for an individual item to complete
  • How long it took for the entire set of work to complete

Based on this, I built a prototype that consisted of a process of 4 distinct steps, and each variation of process control to track/control/observe progress. You can find the entire set of code on my GitHub.

Here’s what I found:

Process Total Time Average Median Observer 6:28 0.1 sec <0.1 sec Controller 6:25 3:25 3:37 Routing Slip 2:57 2.6 sec <0.1 sec

Both the observer and controller styles took roughly the same total amount of time. This is mostly because they have to process the same total amount of messages. The observer took slightly longer in my tests, because the observer is more likely to get exceptions for trying to start the same saga twice. But once an item began in the observer, it finished very quickly.

On the controller side, because all messages get funneled to the same queue, adding more messages meant that each individual item of work would have to wait for all previous items to complete.

Finally, the routing slip took less than half the time, with higher total average but comparable median to the observer. On the routing slip side, what I found was that the process sped up over time as the individual steps “caught up” with the rate of incoming messages to start the process.

This was all on a single laptop, so no network hops needed to be made. In practice, we found that each additional network hop from a new message or a DB call for the saga entity added latency to the overall process. By eliminating network hops and optimizing the total flow, we’ve seen in production total processing times decrease by an order of magnitude based on the deployment topology.

This may not matter for small numbers of messages, but for many of my systems, we’ll have 100s of thousands to millions of messages dropped on our lap, all at once, every day. When you have this situation, more efficient processing patterns can alleviate pressure in completing the work to be processed.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Five Tips for Tactical Management

Johanna Rothman - Tue, 10/28/2014 - 19:15

Sometimes, you just need to get on with the work. You need to give yourself some breathing room so you can think for a while. Here are some tips that will help you tackle the day-to-day management work:

  1. Schedule and conduct your one-on-ones. Being a manager means you make room for  the people stuff: the one-on-ones, the coaching and feedback or the meta-coaching or the meta-feedback that you offer in the one-on-ones. Those actions are tactical and if you don’t do them, they become strategic.
  2. As a manager, make sure you have team meetings. No, not serial status meetings. Never those. Problem solving meetings, please. The more managers you manage, the more critical this step is. If you miss these meetings, people notice. They wonder what’s wrong with you and they make up stories. While the stories might be interesting, you do not want people making stories up about what is wrong with you or your management, do you?
  3. Stop multitasking and delegate. Your people are way more capable than you think they are. Stop trying to do it all. Stop trying to do technical work if you are a manager. Take pride in your management work and do the management work.
  4. Stop estimating on behalf of your people. This is especially true for agile teams. If you don’t like the estimate, ask them why they think it will take that long, and then work with them on removing obstacles.
  5. If you have leftover time, it’s time to work on the strategic work. What is the most important work you and your team can do? What is your number one project? What work should you not be doing?  This is project portfolio management. You might find it difficult to make these decisions. But the more you make these decisions, the better it is for you and your group.

Okay, there are your five tips. Happy management.

Categories: Blogs

ScanAgile 2015 submissions are open!

Software Development Today - Vasco Duarte - Tue, 10/28/2014 - 19:15

Just a quick note today to let you know that the Call for Sessions for ScanAgile, the Agile Finland annual conference is open for submissions.
You can read the whole call for sessions here. You will find the submission form in that page as well.

For me the most interesting tracks are:

  • Off-Piste: interesting lessons learned about being agile and agile related topics, from other industries 
  • Black Piste: Topics for experienced agile practitioners
These are just some of the tracks. In Scan Agile there will also be tracks for those starting up or that have already started but are in the early phases of their Agile transformation journey. 

The Agile Finland Community is very active and has a long history of agile adoption and promotion. They have some of the most advanced practitioners in the world, so I am really looking forward to see who the Scan Agile team chooses for the 2015 lineup of the conference! 

Hope to see many of you there! 
Categories: Blogs

Removing Barriers To Scaling Agile Adoption: An Introduction

Danube - Tue, 10/28/2014 - 18:54

 An IntroductionWhen Agile software development practices are introduced into an organization, they often spread faster than they can be controlled.

Without a clearly defined standard to guide your implementation, numerous Agile management approaches can emerge simultaneously—sometimes in direct conflict with one another. That’s not necessarily a bad thing, but traditional, top-down management structures typically experience some growing pains as they transition to the more egalitarian Agile approach. As an executive, how do you embrace Agile yet mitigate risks in scaling technology, people and processes?

This blog series attempts to answer that question and offer a road map to scale Agile adoption for enterprises embarking on that journey. I’ll present common roadblocks you are likely to encounter along the way.

These impediments, which will be the topics for this blog series, can be classified in four main categories: people; processes; technology; and teams, management, and culture.  Let’s explore the first topic.

Which enterprises will successfully adopt agile?

What types of projects are most suitable for applying Agile practices? It’s even more important to consider the organizational setting where the work gets done. Any project can succeed in Agile; what dictates if it takes off or stalls out are the organiza­tional and cultural constraints of the enterprise.

Lean Software Developer Tom Poppendieck sums this idea up:  “The constraints on when Agile approaches can be used are primarily organizational and cultural, not project types. Some organizations and some contexts are incompatible with Agile/Lean thinking. When these organizations eventually come up against a strong competitive threat, they will fail to meet it unless they change their values and mindsets. Lean/Agile is, at its foundation, the fourth industrial paradigm, the first being Craft Production, Factory Production with machine tooling, Automation, and Taylorism. These come along every hundred years or so and take a few decades to work through. Each paradigm includes the preceding one and makes it dramatically more productive.”*

There is no need to sell Agile except to organizations that want to survive long term. If they don’t see the threat/opportunity, they cannot succeed with Agile or Lean nor can they sustain economic viability in the long run.

The best indication that it will be able to make the transition is a willingness to listen and change accordingly. Many organizations insist that they listen to their employees and foster an Agile culture, but that claim is frequently disproved when Agile values conflict with organizational values. Such a culture clash reveals just how deeply embedded traditional waterfall-ish mentalities are. Frequently, enterprises are unwilling to break from habit, even when short range difficulties will yield long- term improvements.

Consider an organization with a lot of up-front analysis and design. How does its employees respond when asked to write User Stories? Do they insist that Use Cases are better than User Stories? Or do they ask to be shown how to write User Stories? The employees who are open to the new paradigm will transition to Agile faster and with better results. Other issues, though, are more tightly woven into the fabric of the organization. Consider an organization that traditionally provides individual offic­es for its developers. How does management respond to the suggestion of common team rooms? Do they justify the status quo or are they willing to experiment with alternatives? In short, for organizations willing to listen and change, there are no issues that cannot be resolved; it is only a matter of time and effort.

That is not to say that change is not disruptive. On the contrary, change of this order sends shockwaves throughout the entire enterprise. When an organization first introduces Agile practices to a team, the team’s difficulties are limited to the immediate adoption of the practices and how they alter their familiar working methods. But after the team acclimates to these new practices, the challenges shift to a larger, team-wide scope. This is how concerns over Agile tend to develop: by shifting from local, individual problems to over-arching, organizational ones. As Agile practices spread throughout an enterprise, the scope and nature of the problems mirrors that growth. Although these issues cannot be anticipated in any absolute sense, it is possible to classify them as groups and highlight some of the most typical challenges organizations encounter, which can be divided into the following four categories: people; processes; technology; and teams, management, and culture.

Next week I will share some thoughts on how to overcome impediments due to overly specialized skill sets, lack of ownership, refusal to work with the team, and mixed signals from management.  


The post Removing Barriers To Scaling Agile Adoption: An Introduction appeared first on

Categories: Companies

VersionOne Announced its 2014 Fall Release

Scrum Expert - Tue, 10/28/2014 - 18:46
VersionOne has announced its 2014 Fall Release which includes native CA PPM integration, advanced project forecasting through Monte Carlo simulation, and portfolio-level reporting with SAFe 3.0. These new capabilities make scaling easier by aligning agile and traditional project teams under a single vision. The new VersionOne capabilities help portfolio managers easily visualize and manage feature-level agile project activity in the context of enterprise business plans: * CA PPM VersionOne native integration: A partnership with CA Technologies delivers an integrated solution that synchronizes agile ALM and PPM to provide a complete picture of ...
Categories: Communities

Toronto Agile & Software, Toronto, Canada, November 10 2014

Scrum Expert - Tue, 10/28/2014 - 18:36
Toronto Agile & Software is a one-day conference focused on Agile software development that takes place in Toronto, Canada. You will gain key insights and learning on the practical implementation of Agile methodologies within companies. Practitioners will find out about the latest developments, tools and methodologies. In the agenda of Toronto Agile & Software you can find topics like “Principle-Centered Agility: Your Path to Better Options”, “Implementing Agile Development in an Enterprise Environment”, “Creating Alignment for Agile Change”, “Agile Architecture and Modeling – Where are we Today?”, “Scrum and Kanban – ...
Categories: Communities

Role of a Project Manager in Scrum

DFW Scrum User Group - Tue, 10/28/2014 - 18:23
We had a great turnout at DFW Scrum last TUE for “The Role of the Project Manager in Scrum”. Many organizations struggle with what to do with the Project Manager when they have a Scrum Team. Chris Eberhardt and myself … Continue reading →
Categories: Communities

Agile Trick or Treat – Terrifying Tales From a Coach in the Crypt

BigVisible Solutions :: An Agile Company - Tue, 10/28/2014 - 17:48

‘Tis the season for ghost, goblins and cute children seeking treats. Halloween is the time to delight in all things creepy and crawly! An Agile Coach, however, sees scary things year round. These are a few of the scariest things and what can be done about them. Eeek! Zombie Product Owners Product Owner is a […]

The post Agile Trick or Treat – Terrifying Tales From a Coach in the Crypt appeared first on BigVisible Solutions.

Categories: Companies

SonarQube supports ECMAScript 6

Sonar - Tue, 10/28/2014 - 13:53

The 2.1 version of the JavaScript Plugin fully supports ECMAScript 6 (ES6). But what does that mean exactly ?

What is ECMAScript 6 ?

Let’s start from the beginning. The JavaScript language is one implementation of the ECMAScript language standard. (JScript and ActionScript are two more.) Each browser has its own JavaScript interpreter, and most modern browsers support the ECMAScript 5 (ES5) standard. That means that you can write JavaScript that adheres to the ES5 standard and have it work correctly for the vast majority of your users.

ES6 is the next version of the standard, and it provides great new features to allow you to write shareable, efficient, and readable code more easily. Luke Hobbans is a member of TC39, the committee behind ECMAScript. He’s written up a great summary, of the main features of ES6, including a short description of each, complete with code snippet.
Here’s a quick sample for 2 new constructs, variable and constant declaration, and arrow function:

Block scoped binding construct: let for variable declaration and const for constant declaration.

const a = 1;
a = 2;  // error - cannot be re-assigned

if (true) {
  let b = 1;
print(b);  // b is undefined

Arrow function: function shorthand using the => syntax.

let sum = (a, b) => a + b;
Can I use ES6 today ?

A new version of the standard also means that each browser needs to provide support for it, at least the major ones. It might take years before it happens, but you don’t have to wait for that to take advantage of the innovations in ECMAScript 6!
Thanks to the availability of ES6-to-ES5 transpilers, it is possible to use ES6 features today. A transpiler will translate your ECMAScript 6 code to ECMAScript 5 code so it can be run by today’s browsers. I like the Traceur compiler, which offers an online demo. You can enter ES6 on the left side and see the resulting ES5 code on right.
AngularJS has already taken advantage of a transpiler to make the move with AngularJS 2.0.

You can follow the progress of ES6 support in browsers and for transpilers in Juriy Zaytsev’s ES6 compatibility matrix.

Use SonarQube to analyze ES6 code

The SonarQube JavaScript Plugin 2.1 fully supports ES6. What does that mean?

It means that the plugin is able to:

  1. parse ES6 source code,
  2. compute all relevant metrics accordingly:
    • a classes count is computed when classes are used
    • class complexity is computed when classes are used
    • the function count includes generator functions
    • general complexity metrics take generators into account
    • the number of accessors is now computed
  3. analyse code against rules, all existing coding rules have been updated to cover the new features, e.g: “unused variable” will detect unused variables & constants declared with let and const.

In upcoming versions, we’ll be adding new rules specific to ES6 features. We’re still figuring out what those should be, but a set of rules about classes is likely. If you’ve got suggestions, please let us know at

Wanna see a live demo? Check out Angular DI Framework using ES6 on nemo: Angular Dependency Injection v2.

Categories: Open Source

Purpose, not Features

NetObjectives - Tue, 10/28/2014 - 12:51
I keep hearing people ask about how to improve agile requirements. I agree that mere decomposition of epics into features into stories into right sized stories into tasks is not enough. In fact, it misses the point. In fact, most of the time customers don't know what they want. Henry Ford said - "If I had asked people what they wanted they would have said 'faster horses'".  So how can we find out...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Agile Assessments – A Deeper Dive

Leading Agile - Mike Cottmeyer - Tue, 10/28/2014 - 12:50

In my previous post Agile Assessments, I wrote about reasons to do an assessment and considerations when doing one.  In this post, I’ll continue the assessment topic with focus on Rating Scales and Frequency.

Select a Rating Scale

When conducting an agile assessment or self-assessment, an understandable rating scale should be used that allows the rater to assign a value to the practice or capability being rated.

Using Numbers

A Scale of 1 to n is so common it has become part of our vocabulary and for good reason:  It’s easy to understand and very straightforward.

Including a qualitative description of each number in the scale will improve the usefulness of the rating scale. For example, if a rating of 2 is described as “Apprentice” or “Beginner”, the category is more likely to mean the same thing to different people. And if we expand the definition further, the raters are even more likely to apply the rating similarly.  Let’s look at this further in the following example:

Numeric Only Numeric + Minor Qualification Numeric + Detailed Qualification 0 0 – Not started 0 – Not started – The practice/capability is not yet understood and/or is not yet in use by the team 1 1 – Apprentice 1 – Apprentice – Beginning to learn and apply practice/capability. Guidance from experts is recommended. 2 2 – Journeyman 2 – Journeyman – Practice/capability is well understood and is sustainable by the team. 3 3 – Expert 3 – Expert – Practice/capability is fully internalized. Team can teach and mentor others.

Each level of qualification brings more clarification and shared understanding of the numeric rating.  Keep this in mind when you select a scale and include a description for each that will help the raters apply the scale with some degree of consistency.  Consistency in the interpretation of the rating scale will be important to a team as they continue to self-assess periodically.  It is also important for the organization when measuring progress across teams to get an overall view of an agile transformation.

Using Colors and Symbols

Graphic/visual representations, in addition to or instead of a numeric scale, can bring life to the assessment process and quick interpretation of the assessment results, particularly if you have an open work space to display them.  Standard traffic light colors, plus black, offer a simple translation:

◉ Black – Not Started
◉ Red – Practice/capability has started but needs significant improvement
◉ Yellow – We are practicing the competency consistently
◉ Green – Team has fully embraced practice/capability and internalized it into culture

You often see the use of four/five stars in online ratings of movies, books and restaurants and we all understand that a ‘5 star hotel’ is very luxurious and comes with many amenities.  Our assessment star rating scale would look something like this:

★★★★★ – Not started
★★★★★ – Just beginning use of practice/capability
★★★★★ – Practice/capability is understood but not used consistently
★★★★★ – Practice/capability is used most of the time
★★★★★ – Demonstrable evidence practice/capability has been mastered
★★★★★ – Teaching and mentoring others on practice/capability

Like the traffic light colors, it’s a visual rating that we’re used to seeing and doesn’t require a lot of thought to interpret.  The stars really do represent numbers though and you can choose to use them mathematically and roll up scores to a major category level or overall assessment score.

My preference when conducting an assessment for an organization where I am the rater is to use a numeric scale that includes a clear and detailed qualitative description.  This helps me take more time to consider the criteria and the circumstances.  When guiding a team on their self-assessment, I’ve observed that the use of the graphic/visual format takes away the reluctance some individuals have when choosing a number, allows the process to go faster and achieves a result closer to reality.  Personally, I find that I can over think numbers but don’t second guess so much when selecting the color Yellow or 4 Stars.  You may not find this true if you’re not a visual thinker.

How Often Should You Reassess?

If you look back at some of the reasons to do an assessment from my Agile Assessments post, many of them set the expectation that it’s a recurring activity.  A few from the list include: “Establish Baseline”, “See how you’re tracking against your transformation goals”, and “Determine if you’re ready to move to next level”.  While ideally you’re already using metrics to improve your processes in general, an agile assessment or assessment instrument has a more specific purpose and lifespan in support of an agile transformation.   Once a team and/or organization reaches a greater level of maturity in their adoption and agile becomes ’the way you build software”, the assessment instrument will largely cease to provide value.  It doesn’t mean you stop continuously improving but we have the retrospective for that.

The frequency of the assessment should take into consideration the rate of change you’re expecting between assessments. For example, if I assess a new team, send them to training and leave them mostly alone to figure it out, I’m not going to anticipate a great deal of improvement in the next 30 days and therefore, I may wait a couple months to re-assess.  Contrast that with a team who is given training, has a scrum master or other leader on the team with agile experience, and they also have continued and focused coaching.  I would expect to see change in a months time and will want to have visibility to the progress via the assessment results.  Every few sprints is a good, general guideline when you’re getting started.  Once you set the interval, stick to it.

Most important to me is that someone is using the assessment results for a clear purpose.  I’ve seen teams complete their self-assessment on a regular cadence because the organization required them to but do absolutely nothing with it.  I know the company was truly interested in understanding how their transformation was progressing and to know where support was needed for the team but the assessment results weren’t being used to understand progress or areas for improvement.  If the results aren’t being used or understood, it might be time to step back and re-evaluate.

On to Methods and Results

You can look forward to my next post where I’ll share a few different approaches for administering an assessment and how to report your results.

The post Agile Assessments – A Deeper Dive appeared first on LeadingAgile.

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.