Skip to content

Feed aggregator

Refactoring JavaScript from Sync to Async in Safe Baby-Steps

Mistaeks I Hav Made - Nat Pryce - Sat, 08/08/2015 - 18:10
Consider some JavaScript code that gets and uses a value from a synchronous call or built in data structure: function to_be_refactored() { var x; ... x = get_x(); ...use x... } Suppose we want to replace this synchronous call with a call to a service that has an asynchronous API (an HTTP fetch, for example). How can we refactor the code from synchronous to asynchronous style in small safe steps? First, wrap the the remainder of the function after the line that gets the value in a “continuation” function that takes the value as a parameter and closes over any other variables in its environment. Pass the value to the continuation function: function to_be_refactored() { var x, cont; ... x = get_x(); cont = function(x) { ...use x... }; cont(x); } Then pull the definition of the continuation function before the code that gets the value: function to_be_refactored() { var x, cont; cont = function(x) { ...use x... }; ... x = get_x(); cont(x); } Now extract the last two lines that get the value and call the continuation into a single function that takes the continuation as a parameter and pass the continuation to it. function to_be_refactored() { ... get_x_and(function(x) { ...use x... }); } function get_x_and(cont) { cont(get_x()); } If you have calls to get_x in many places in your code base, move get_x_and into a common module so that it can be called everywhere that get_x is called. Transform the remaining uses of get_x to “continuation passing style”, replacing the calls to get_x with calls toget_x_and. Finally, replace the implementation of get_x_and with a call to the async service and delete the get_x function. Wouldn’t it be nice if IDEs could do this refactoring automatically? The Trouble With Shared Mutable State Dale Hagglund asked via Twitter “What if cont assumes that some [shared mutable] property remains constant across the async invocation? I’ve always found these very hard to unmake.” In that case, you’ll have to copy the current value of the shared, mutable property into a local variable that is then closed over by the continuation. E.g. function to_be_refactored() { var x; ... x = get_x(); ...use x and shared_mutable_y() ... } would have to become: function to_be_refactored() { var y; ... y = shared_mutable_y(); get_x_and(function(x) { ...use x and y... }); }
Categories: Blogs

SPC Reading List

Agile Product Owner - Fri, 08/07/2015 - 20:46
SPC Reading List

We hope you are having a safe and enjoyable summer!  Don’t forget the hat, sunglasses and sunscreen!  We will be updating our SPC Reading list and thought it would be a good idea to share this with you now.  Summer is a great time to catch up on your reading, while enjoying SAFe time in the sun.

  • Principles of Product Development Flow, Don Reinertsen
  • The Lean Machine, Dantar Oosterwal
  • Leading SAFe Live Lessons (Video Book),  Dean Leffingwell
  • Lean Product and Process Development, Allen Ward and Durward Sobeck II
  • The Goal, Eliyahu Goldratt
  • Out of the Crisis, E. Deming
  • Agile Software Requirements, Dean Leffingwell
  • Switch, Chip Heath and Dan Heath
  • The Five Dysfunctions of a Team, Patrick Lencioni

For those in the Southern Hemisphere, we haven’t forgotten about you and hope that you are having a mild and safe winter.  When it’s cold out, nothing like a good book to read under the warm covers or by the fireplace.

Always be SAFe,

Richard

Categories: Blogs

Making Workflow Explicit In JavaScript (Repost)

Derick Bailey - new ThoughtStream - Fri, 08/07/2015 - 18:13

A long time ago, in what seems to be a previous life at this point, I wrote a small blog post about modeling and creating an explicit return value from a dialog form in a Windows application. Fast forward a lifetime and I’m finding that this knowledge and experience is resurfacing itself in my daily work with. Whether it’s Backbone and Marionette or Node.js and RabbitMQ, I’ve used this pattern that I first learned in WinForms and my applications have benefited greatly from it.

Confused workflow

A Poorly Constructed Workflow

It seems to be common in the JavaScript world to have very poorly defined and constructed workflow in applications. We take one object and build some functionality. Then when the next part of the app needs to fire up, we call it directly from the first object. Then when the next part of the app is requested, we call that object from the second one. And we continue on down this path ad-infinitum, creating a mess of tightly coupled concerns, tightly coupled concepts, tightly coupled objects, and a fragile system that is dependent entirely on the implementation details to understand the higher level process.

Consider this example: a human resources application allows you to add a new employee and select a manager for the employee. After entering a name and email address, the form to select the manager should be shown. When save is clicked, the employee should be created. A crude, but all too common implementation of this workflow might look something like this:

Can you quickly and easily describe the workflow in this example? If you can, you probably paid attention to the description above. Look at the code again, and follow the workflow through the code.

Personally, I have to spend a fair amount of time looking at the implementation details of both views in order to see what’s going on. I have to piece together the bits of the workflow from multiple places to form a more coherent, high level overview in my head. It’s not easy for me to see what’s going on. Every time I look at one part of the code, I have to mentally dig through implementation details that cloud the vision of the high level workflow. This is time consuming and prone to mistakes.

Too Many Concerns

This code has a number of different concerns mixed in to very few objects, and those concerns are split apart in some rather un-natural ways. To understand the complete concern, code from different parts of the app have to be mentally put back together. But, what are the concerns that are presented in this code?

The first set of concerns are found in the high level workflow:

  • Enter employee info
  • Select manager
  • Create employee

The second set of concerns are what should be the implementation detail:

  • Show the EmployeeInfoForm 
  • Allow the user to enter a name and email address
  • When “next” is clicked, gather the name and email address of the employee
  • Then show the SelectManagerForm with a list of possible managers to select from
  • When “save” is clicked, grab the selected manager
  • Then take all of the employee information and create a new employee record on the server

This list doesn’t even cover all of the edge cases or common scenarios. What happens when the user hits cancel on the first screen? Or on the second? What about invalid email address validation? Adding these steps to the list of implementation details has things getting out of hand very quickly.

By implementing both the high level workflow and the implementation detail in the views – the details and implementation – the ability to see the high level workflow at a glance has been destroyed. This will cause problems as details will be forgotten when changing the system. Code will be broken. Features will be missing. Adding more to the process – like the validation or cancel buttons that are already missing – will make it more complicated, still. 

This situation has to change.

Modeling An Explicit Workflow In Code

Instead of tightly coupling the workflow to the implementations, the high level workflow should be extracted. The governing process for this part of the application should be made explicit in the code, in a way that makes it easy to see the over-all flow.

Think of a workflow diagram as an example. The diagram doesn’t show all of the details. It shows the high level steps. Each step may be composed of additional detail, but the diagram shows it simplified in to single boxes.

Code should be modeled in the sam manner. The workflow should be high level, showing the basic steps. Detail of each step should be modeled in to other objects that are called by the workflow. This makes it easier to change the workflow and to change any specific implementation detail without having to rework the higher level process.

Consider this code, for example:

Here, the high level workflow is easier to see. After the employee info is entered, the manager selection comes up next. When that completes, the employee info is saved. It all looks very clean and simple. More importantly, the additional features like validation and cancel buttons can be added to the code. The validation may be a detail that happens in the individual form, but the cancel button is likely to be a part of the high level workflow.

From here, at the workflow level, moving to the details can be accomplished with a couple of Backbone views and a model for the details:

(I’ve omitted some of the details of the views and model, but I think the idea is there)

The Benefits

There are a number of benefits to writing code in this manner:

  • It’s easy to see the high level workflow
  • You don’t have to worry about all of the implementation details for each of the views or the model when dealing with the workflow
  • You can change any of the individual views without affecting the rest of the workflow
  • Adding new features or process to the workflow is easier
  • (and more!) 

Of all the benefits listed and the ones that I am not thinking of at the moment, the most important one may be the ability to see the high level workflow. 6 months from now – or if you’re like me, 6 hours from now – you won’t remember that you have to trace through 5 different Views and three different custom objects and models, to piece together the workflow. But if you have a workflow modeled explicitly, you’re more likely to pick up the code and understand the process quickly.

The Drawbacks

Everything has a price, right?

You will end up with a few more objects and a few more methods to keep track of. There’s a mild overhead associated with this in the world of browser based JavaScript, but that’s likely to be so small that you won’t notice – especially with the rapid rate of optimization in JavaScript engines.

The real cost, though, is learning new implementation patterns to get this working. That takes time. Sure, looking at an example like this is easy. But it’s a simple example and a simple implementation. When you get down to actually trying to write this style of code for yourself, it will be more complicated. There’s no simple answer for this problem, either. You have to learn through it in order to improve your application design.

It’s Worth It

In the end and in spite of potential drawbacks and learning curves, explicitly modeling workflow in your application is important.

It really doesn’t matter what language your writing in, either. I’ve shown these examples in JavaScript and Backbone because that’s where I’m seeing a lot of need for this, recently. But I’ve applied these same rules to C#/.NET, Ruby and other languages for years.

As with any good architecture and philosophy, the principles are the same across languages and other boundaries. It’s only the implementation details that change.

 

(This article was originally published on LosTechies, and has been revised and edited here)

Categories: Blogs

Spark: Convert RDD to DataFrame

Mark Needham - Thu, 08/06/2015 - 23:11

As I mentioned in a previous blog post I’ve been playing around with the Databricks Spark CSV library and wanted to take a CSV file, clean it up and then write out a new CSV file containing some of the columns.

I started by processing the CSV file and writing it into a temporary table:

import org.apache.spark.sql.{SQLContext, Row, DataFrame}
 
val sqlContext = new SQLContext(sc)
val crimeFile = "Crimes_-_2001_to_present.csv"
sqlContext.load("com.databricks.spark.csv", Map("path" -> crimeFile, "header" -> "true")).registerTempTable("crimes")

I wanted to get to the point where I could call the following function which writes a DataFrame to disk:

private def createFile(df: DataFrame, file: String, header: String): Unit = {
  FileUtil.fullyDelete(new File(file))
  val tmpFile = "tmp/" + System.currentTimeMillis() + "-" + file
  df.distinct.save(tmpFile, "com.databricks.spark.csv")
}

The first file only needs to contain the primary type of crime, which we can extract with the following query:

val rows = sqlContext.sql("select `Primary Type` as primaryType FROM crimes LIMIT 10")
 
rows.collect()
res4: Array[org.apache.spark.sql.Row] = Array([ASSAULT], [ROBBERY], [CRIMINAL DAMAGE], [THEFT], [THEFT], [BURGLARY], [THEFT], [BURGLARY], [THEFT], [CRIMINAL DAMAGE])

Some of the primary types have trailing spaces which I want to get rid of. As far as I can tell Spark’s variant of SQL doesn’t have the LTRIM or RTRIM functions but we can map over ‘rows’ and use the String ‘trim’ function instead:

rows.map { case Row(primaryType: String) => Row(primaryType.trim) }
res8: org.apache.spark.rdd.RDD[org.apache.spark.sql.Row] = MapPartitionsRDD[29] at map at DataFrame.scala:776

Now we’ve got an RDD of Rows which we need to convert back to a DataFrame again. ‘sqlContext’ has a function which we might be able to use:

sqlContext.createDataFrame(rows.map { case Row(primaryType: String) => Row(primaryType.trim) })
 
<console>:27: error: overloaded method value createDataFrame with alternatives:
  [A <: Product](data: Seq[A])(implicit evidence$4: reflect.runtime.universe.TypeTag[A])org.apache.spark.sql.DataFrame <and>
  [A <: Product](rdd: org.apache.spark.rdd.RDD[A])(implicit evidence$3: reflect.runtime.universe.TypeTag[A])org.apache.spark.sql.DataFrame
 cannot be applied to (org.apache.spark.rdd.RDD[org.apache.spark.sql.Row])
              sqlContext.createDataFrame(rows.map { case Row(primaryType: String) => Row(primaryType.trim) })
                         ^

These are the signatures we can choose from:

2015 08 06 21 58 12

If we want to pass in an RDD of type Row we’re going to have to define a StructType or we can convert each row into something more strongly typed:

case class CrimeType(primaryType: String)
 
sqlContext.createDataFrame(rows.map { case Row(primaryType: String) => CrimeType(primaryType.trim) })
res14: org.apache.spark.sql.DataFrame = [primaryType: string]

Great, we’ve got our DataFrame which we can now plug into the ‘createFile’ function like so:

createFile(
  sqlContext.createDataFrame(rows.map { case Row(primaryType: String) => CrimeType(primaryType.trim) }),
  "/tmp/crimeTypes.csv",
  "crimeType:ID(CrimeType)")

We can actually do better though!

Since we’ve got an RDD of a specific class we can make use of the ‘rddToDataFrameHolder’ implicit function and then the ‘toDF’ function on ‘DataFrameHolder’. This is what the code looks like:

import sqlContext.implicits._
createFile(
  rows.map { case Row(primaryType: String) => CrimeType(primaryType.trim) }.toDF(),
  "/tmp/crimeTypes.csv",
  "crimeType:ID(CrimeType)")

And we’re done!

Categories: Blogs

How to Become a Software Craftsman

Agile Management Blog - VersionOne - Thu, 08/06/2015 - 14:30

Craftmanship

 

 

 

 

 

 

 

How to become a Software Craftsman has become a huge subtext in the software community and the development conversation. One of the things that I’ve been exploring is how do we get there? How do we go from where we are to becoming  true software craftsmen?

It’s not this magical “Oh, we’re agile, we put posters of the manifesto everywhere, so now we’re agile and we’re software craftsmen.” It takes work, and it takes activities. I’ve been doing a lot of exploration into this and believe I have discovered three paths to the summit of software craftsmanship.

Software Craftsman Defined

Let’s first define what I mean by a software craftsman. Everybody has their own views, but I think of a software craftsman as someone who has practiced the techniques of XP, agile, and DevOps till those techniques have worked themselves into the person’s subconscious. This software craftsman creates software using these techniques almost through muscle memory. They no longer have to think about what they need to do to create beautiful code, they just execute in their relentless pursuit of creating amazing software products.

How You Get to be a Software Craftsman

So now that we have defined what being a software craftsman means to me, let’s explore how we get there. I’ve found that there are three paths to becoming a software craftsman. These paths are comprised of software development skills that need to be developed. The first path develops the people skills, the second path develops the technical skills and the third path explores the principles derived from the other two paths.

Let’s survey what each of these paths covers.

The People Path

One of aspects that I’ve been exploring a lot is that there are people problems and there are technical problems to DevOps and software craftsmanship. Of course, the technical skills are critical, but no more so than the people side. Just like it does a person no good to only strengthen their right arm, while their left atrophies, it does us no good to only strengthen our technical skills, while our people skills go to waste.

We must learn and apply technical tools from a people perspective. Craftsmanship means doing things by hand and knowing how to execute with an artist’s touch. It’s not enough to say, “I expect you to be doing test-driven development.” You have to be able to help people understand what test-driven development is.

Those of us in the software development community must help foster craftsmanship because it certainly isn’t being taught in school. The typical computer science college graduate does not understand how to do test-driven development or agile. We’re making some progress, but it’s still not good enough.

The Technical Path

There is also the technical side to keep in mind. Practices include test-driven development, refactoring and continuous integration. It is also important to know when and how to write acceptance tests and how to apply these as well as how to automate these. These are the nuts and bolts of a solid software craftsman. The idea of refactoring becomes part of daily life, not just using the buzzword but intuitively building it into everything you do.

These are the steps you’re going to continue with, and at some point that will lead you to DevOps and continuous delivery. These technical practices and methodologies are more organizational than individualized, but DevOps and continuous delivery do require a discipline that only a software craftsman can really, truly supply.

The Principles Path

I’ve found that you can break this down into certain areas of foundational skills that need to be developed. The first of those foundational skills is coding. Sounds kind of silly to say it, but it’s worth saying; a programmer needs to be excellent at coding.

Coding

By coding I don’t mean one language. You must be astute in multiple languages. No true craftsman only knows one way of doing anything. It doesn’t matter what languages, but there needs to be at least two, preferably more.

Design

Designing is an important aspect, but is tricky in the agile world because we say, “don’t get caught up in big, up front designing.” I believe that, but you do need to understand design. Whether it be unit design, large architectural pieces or systems design, you do need to understand and be able to apply good design.

Applying Agile Principles

Learning the 12 principles of the Agile Manifesto isn’t very difficult; applying them is much harder. You have to understand when they apply, when simplicity really is essential, what simplicity is and how to apply simplicity to a particular problem.

Tooling

We have many tools available to us. Mastering these tools as a true craftsman is not about simply using them, it’s about knowing how to use them wisely. Like the saying goes, “If you need a hammer, whatever tool is handy is a hammer.” That’s not necessarily the best approach. A craftsman seeks the right tool for the right job and uses that tool masterfully.

Work Habits

You need to be able to establish strong work habits. You need to be able to, not just by yourself, but in a team, practice these habits. Test-driven development and continuous integration are tools to help us with practice our work habits. Having the work habits and the discipline around those work habits to be able to say yes or no and to be able to say, “This is what I need to do, and it’s what I will do” is crucial.

Professionalism

Professionalism is something you notice more often when it’s not there than when it is. There is a quiet confidence and understanding in professionals. There is the ability to know where you’re going and what you’re doing without conscious thinking. You have confidence in professionals because you know that they will do great work. That’s what I mean by professionalism, it’s very difficult to define, but it’s absolutely vital to a strong development shop. Especially, as we aspire to craftsmanship.

Traditional Craftsman Education

To learn how to teach software craftsmanship, we have to look no further than the trades where craftsmanship originated. Traditionally, craftsmen were created through apprenticeships. By going through an apprenticeship program, young craftsmen, no matter what their background or their education, learn not just what they should do but how to do it. They’d learn the tricks and techniques that don’t necessarily come just from reading a book, taking a class or passing a test. It’s about learning from doing, and it’s learning by doing things together.

The next component of how craftsmanship has been historically taught is recognizing progress. To recognize progress, you need a path to follow. It’s no secret that there’s no really well-defined career path for software developers.

The typical path of a developer is to start as a junior software engineer, progress to a senior software engineer and, if you’re really good, you become a tech lead. As a tech lead, you have to now tell other people how to do it. Then, if you’re really good at that, they take you completely out of the thing you love, which is programming, and make you a manager. Then, you get to try to figure out how to make other people do what you love to do most. That path has never really worked.

Micro-certifications are becoming very popular in the world of education and development. Think of micro-certifications as similar to boy scout badges. You could have a badge in test-driven development, concrete data systems or web design. By obtaining these badges, you can recognize progress and simultaneously you can be recognized for that progress. When taking an approach such as this you should start associating some of the compensation and programs with the development of these badges.

When you are done with your apprenticeship, you are, of course, not done learning. At this stage, you grow into a journeyman. A journeyman is a very time-honored tradition. The idea of a journeyman is that now you are good enough to go out on your own. In the traditional craftsmanship model, a journeyman would have wandered from village to village practicing their craft.

In the software world, this might mean you work on a team for a year or maybe two. Then, you go to another team. The wandering part doesn’t have to be quite as frequent as the traditional journeyman, but the idea is that you need to continue to develop your skills and to develop them not in a single place but to explore other areas.

If you’ve been doing nothing but data mining for six months, then maybe for the next six months you should be focused on webpages so that you are building a broad base of skills. That’s what a journeyman’s life is. We should be spending the majority of our time as journeymen.

Conclusion

These are the steps. It’s not the easiest path in the world, but it’s absolutely worth it as you go along. We should all aspire to be great at our craft and be true craftsmen in our discipline. I hope this has inspired you to take a look at what areas you can develop to become a stronger software craftsman.

What other skills do you think are important for a software craftsman to develop?

About the Author

versionone-coaches-steve-ropaSteve Ropa
CSM, CSPO, Innovation Games Facilitator, SA
Agile Coach and Product Consultant, VersionOne

Steve has more than 25 years of experience in software development and 15 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.

Categories: Companies

Agile Hotline – Is agile more efficient than waterfall?

Growing Agile - Thu, 08/06/2015 - 13:43
Question Recently someone asked for advice about a debate he was having with a co-worker about whether agile and Scrum can work in any software development scenario. The co-worker argued that it couldn’t. This was his scenario Say we are working on building a software product that allows user’s to take assessments while reading an […]
Categories: Companies

Article published on Information Age: Why expert developers make the worst tech leads

thekua.com@work - Thu, 08/06/2015 - 09:46

Promoting your best or most experienced developer to lead a technology team may seem like a logical move, but it could prove to be a disastrous decision

I recently published a new article on the Information Age website: “Why expert developers make the worst tech leads.” You can read more here.

Categories: Blogs

Hugh MacLeod’s Illustrated Guide to Life Inside Microsoft

J.D. Meier's Blog - Wed, 08/05/2015 - 20:32

imageIf you remember the little blue monster that says, “Microsoft, change the world or go home.”, you know Hugh MacLeod.

Hugh is the creative director at Gaping Void.  I got to meet Hugh, along with Jason Korman (CEO), and Jessica Higgins, last week to talk through some ideas.

Hugh uses cartoons as a snappy and insightful way to change the world.  You can think of it as “Motivational Art for Smart People.”

The Illustrated Guide to Life Inside Microsoft

One of Hugh’s latest creations is the Illustrated Guide to Life Insight Microsoft.  It’s a set of cards you can flip, with a cartoon on the front, and a quote on the back.  It’s truly insight at your fingertips.

image

I like them all … from “Microsoft is a ‘Get Stuff Done’ company” to “Software is the thing between the things”, but my favorite is:

“It’s more fun being the underdog.”

It’s a reminder how you can take the dog out of the fight, but you can’t take the fight out of the dog, and as long as you’re still in the game, and you are truly a learning company, and a company that continues to grow and evolve, you can change the world … your unique way.

Tweaking People in the Right Direction

Hugh is an observer and participant who inspires and prods people in the right direction …

Via Hugh MacLeod Connects the Dots:

“’Attaching art to business outcomes can articulate deep emotions and bring things to light fast,’ said MacLeod. To get there requires MacLeod immersing himself within a company, so he can look for what he calls ‘freaks of light’—epiphanies about a company that express the collected motivations of its people. ‘My cartoons make connections,’ said MacLeod. ‘I create work in an ambient way to tweak people in the right direction.’”

Via Hugh MacLeod Connects the Dots:

“He’s an observer and a participant, mingling temporarily within a culture to better understand it. He’s also a listener, taking your thoughts and combining them with his own to piece together the puzzle he is trying to solve about the human condition and business environment.”

Check out the Illustrated Guide to Life Inside Microsoft and some of the ideas just might surprise you, or, at least inspire and motivate you today – you smart person, you.

Categories: Blogs

AutoMapper 4.0 Released

Jimmy Bogard - Wed, 08/05/2015 - 18:46

Release notes here: https://github.com/AutoMapper/AutoMapper/releases/tag/v4.0.0

On NuGet of course.

This was a big release – I undertook the exciting challenge of supporting all the new platforms from VS 2015, and in the process, collapsed all of the projects/assemblies into exactly one assembly per target framework. It’s much easier to manage on my side with just the one project instead of many different ones:

I have to use compiler directives instead of feature discovery, but it’s a tradeoff I’m happy to make.

There’s a ton of small bug fixes in this release, quite a few enhancements and a few larger new features. Configuration performance went up quite a bit, and I’ve laid the groundwork to make in-memory mapping a lot faster in the future. LINQ projection has gotten to the point where you can do anything that the major query providers support.

Enjoy!

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

Categories: Blogs

Pitfall of Scrum: ScrumMaster as Contributor

Learn more about our Scrum and Agile training sessions on WorldMindware.com

The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle. Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions. Let’s look at each of these aspects of the ScrumMaster role in turn:

The ScrumMaster Helps the Team Follow the Rules of Scrum

The ScrumMaster is a process facilitator. The Scrum process, while simple to describe, is not easy to do. As the Scrum Guide says:

Scrum is:

Lightweight

Simple to understand

Difficult to master

The ScrumMaster helps the Scrum Team and the organization to master the Scrum framework. Helping everyone understand Scrum and respect its rules is a first step. Some of the rules are particularly challenging. In some companies, being on time for meetings and ending them on time is hard. Scrum requires this. The ScrumMaster helps the team do this. In some companies, meeting deadlines, even short ones, is difficult. Scrum requires this every Sprint. The ScrumMaster helps the team do this. In some companies, giving time to improving things is hard. Scrum Teams do retrospectives. The ScrumMaster ensures that the team takes the time for this.

Of course, following the rules is hard for people. Even just the concept of “rules” is hard for some people. Everyone has the right to do whatever they want. Well, if you aren’t following the rules of Scrum you aren’t doing Scrum. So for some teams, just getting to the point of being willing to follow the rules of Scrum is a big step. The ScrumMaster needs to help with motivation.

The ScrumMaster is Vigorously Removing Obstacles

The Scrum Team is going to be working hard to meet a goal for the Sprint. As they work, they are going to work through many challenges and problems on their own. However, the team will start to encounter obstacles as well. These obstacles or impediments come from a few sources:

  1. Dependencies on other people or parts of the organization outside the Scrum Team.
  2. Skill gaps within the team.
  3. Burdensome bureaucracy imposed by the organization.
  4. Lack of resources such as tools, equipment, licenses, or even access to funds.

The ScrumMaster needs to work through these.

On a panel talk on Saturday one person said “the scrum master is an administrator, moving cards, updating the burn down. It is an easy job, I think my son could do it.” I then rebutted his remarks….

The ScrumMaster will tackle enterprise operations for their slow error prone deployment process, tackle Sarbox [Sarbanes-Oxley] compliance policy that has been way over-engineered to the point of slowing dev to a crawl, telling the PMO that 3 sets of reports is waste, exhorting the team to try to do unit tests in ABAP (SAP cobol), etc.

Robin Dymond, CST – (Scrum Training and Coaching Community Google Group, Sep. 23, 2009)

The ScrumMaster is Protecting the Team from Interruptions

Every organization seems to have more work than their staff have the capacity to deliver. Staff are often asked to task switch repeatedly over the course of a day or even in a single hour. Sometimes people are “allocated” to multiple projects simultaneously. This breaks the Scrum value of focus. The ScrumMaster needs to protect the team from interruptions or anything else that would break their focus.

But what should the Scrum Team members be focused on? Simply: the goal of a single Sprint. And a single Scrum Team is focused on a single product. The Product Owner should be the point of contact for any and all requests for the time and effort of a Scrum Team. The ScrumMaster needs to re-direct any interruptions to the Product Owner. The Product Owner decides if:

  • the interruption results in a new Product Backlog Item, OR
  • the interruption is irrelevant to the product and simply discarded, OR
  • the interruption is important enough to cancel the current Sprint.

There are no other options in Scrum for handling requests for work from the Scrum Team (or any member of the Scrum Team).

Contribution as Distraction for the ScrumMaster

Any time the ScrumMaster starts to contribute to the product development effort directly, the ScrumMaster is distracted from the other three duties. Although simple, following the rules of Scrum is not easy. Getting distracted from the duty of helping the team follow the rules of Scrum means that the team is likely to develop bad habits or regress to non-Scrum behaviour. Vigorously removing obstacles is usually a huge job all on its own. Most Scrum Teams have huge organizational obstacle that must be worked on. Some of these obstacles will take years of persistent effort to deal with. The ScrumMaster cannot become distracted by tactical details of product development. Protecting the team from interruptions means the ScrumMaster must have broad awareness, at all times, of what is happening with the team. If a team member is interrupted by a phone call, an email, or someone walking into the Scrum team room, the ScrumMaster needs to notice it immediately.

Whenever a ScrumMaster takes on a product development task, focus on the role is lost and a condition of a simple conflict-of-interest is created. If the team has “committed” to deliver certain Product Backlog Items at the end of a Sprint, then that feeling of commitment may lead a ScrumMaster to focusing on the wrong things.

The time of a ScrumMaster is an investment in continuous improvement. Letting a ScrumMaster contribute to the work of the team dilutes that investment.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

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!
facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Pitfall of Scrum: ScrumMaster as Contributor appeared first on Agile Advice.

Categories: Blogs

What is Flow Debt?

Improving projects with xProcess - Wed, 08/05/2015 - 15:36
+Daniel Vacanti's excellent treatise on Actionable Agile Metrics [vaca] introduces a term that may be unfamiliar, even to those with an interest and experience in managing flow systems. The term is Flow Debt - for a definition and explanation read on.

My own particular interest in flow systems is the management of agile software development teams, usually using some variant of Scrum and/or Kanban, and other agile practices such as test-driven (or automated-test intensive) build-test-deploy processes. However the discussion is relevant in many other domains, such as one I've recently been involved in discussing, the flow of patients through diagnosis, treatment and convalescence in healthcare systems.

In managing these systems we need ways to look at the mass of data that emerges from them to focus on the useful information rather than the noise; information in particular that indicates when intervention is appropriate to improve flow, and when the attempt would be as futile as trying to smooth the waves on an ocean. Flow systems in knowledge work contain variability. That variability, within certain bounds (much wider bounds than in manufacturing for example), is desirable to allow innovation, responsiveness and minimising wasteful planning activities.

In this context Flow Debt is a measure that provides a view of what is happening inside our system. This is in contrast with other important measures such as Throughput (Th) and the time an item stays in the process (I call this "Time in Process", TiP [macc], though other terms may be used). These measures provide information only after items have left the system, which may be too late to avoid problems accumulating.

Having Flow Debt roughly translates as: delivering more quickly now at the cost of slower times later. It is calculated by comparing the time since the number of arrivals into the systems was equal to the current number of deliveries with the average time in the process for the most recent deliveries. It is easiest to visualise this on a Cumulative Flow Diagram.
At the point highlighted in the the diagram it is a little over 2 weeks since the cumulative number of items entering the system equalled the cumulative number of deliveries on that date. If the items were delivered in the precise order they arrived, and if all the items were delivered (neither assumption is true!), then we would be able to say that the time the last item spent in the process was also a little over 2 weeks. Furthermore if arrivals and deliveries were smooth over the period, the Average Time in Process for the items would also be this same time.
What was the actual Average Time in Process though? Well you can't read this off the diagram. You have to look at the average TiP for the items delivered in the recent period. Each one has a known TiP, so take the average of them. Exactly how long the period you select for this average is up to you - a day or a week seems reasonable. The shorter the period you take the more noise there will be in the signal. Take too long a period though and there is insufficient time to act on the information. 
With this information we can calculate Flow Debt using Dan's method[vaca]:Flow Debt = (Time since number of arrivals equalled deliveries) - Average TiPIf you plot this quantity for the data above you get a graph like this. Note I've reversed the sign on this graph to show Flow Debt as negative.The plot of Flow Debt in this case is quite normal showing a fluctuation around zero and maxima and minima of around the value of the average TiP for the whole period. If you plotted the same data with a monthly average, most of this fluctuation would disappear. I certainly wouldn't want managers rushing down to this team to radically change their process!
There is one point highlighted which is interesting, where the Flow Debt goes from highest debt to highest credit in a few days. What do you think is going on here? Well, if you go back to the informal definition of Flow Debt (delivering more quickly now at the cost of slower times later), we should surmise that before this point the delivered items had been in the process for only a short time. Those delivered at or after this point had a longer time in the process. That's exactly what happened, as the Control Chart below shows.Another useful indicator here is the "average age" of the work in progress. Here is the plot of that and you can see the significant drop in this metric at the same point.Just by way of balance let's look at another data set of a team delivering software much less frequently, where their work in progress is increasing over the process, and where the items are not being delivered in age order. All these factors are likely to effect the efficiency and predictability of the flow system... and this is borne out by their plot of Flow Debt.Seeing a plot like this is a indication to management (and flow management specialists in particular) to take a much closer look at the process being used here.
References
Categories: Companies

focus

Derick Bailey - new ThoughtStream - Wed, 08/05/2015 - 12:00

The month of July was almost entirely unfocused for me. I spent more than a week on “vacation” with my family, and I spent another week sick and stuck in my bed. With more than two weeks of downtime, essentially, I feel lost. I feel like I’m not sure of what I’m doing … and I’m scared of that feeling.

focus

It’s more than a bit scary, honestly – the feeling of being unfocused and not knowing what I’m supposed to be working on. I panicked a bit, too, and on the Entreprogrammers podcast, I ended up talking with Josh and John for almost 3 hours because I was panicking about being unfocused.

An Existential Crisis

The kind of focus I’m talking about isn’t the “put twitter down, get back to work” kind. No, I’m talking about the big picture… the “What is my purpose? Why am I here? What is the real value that my business, my blog and my efforts bring to the community?”

It turns out that the 2+ weeks of down time were what I actually needed – even if they weren’t what I wanted. Having that much down time gave me a chance to step back and think for a bit. And the questions I came up with while I was thinking scared me because I was seriously asking “What am I doing? Why?”

I was having a mild existential crisis.

I wasn’t sure what I was doing and I almost deleted my twitter account and stopped working entirely. I didn’t and I’m glad I didn’t. But I was close. Really close.

I Am Unfocused, But Now I Can Fix That

I’ve known that I have been unfocused for a long time now. This is why I shut down SignalLeaf – because I was stretched in too many directions. I had no time to do anything I wanted, and was constantly rushing around in a panic trying to keep things floating. SignalLeaf took a back seat when it should have been a top priority. WatchMeCode languished in the site design and features I wanted to add. My blogging and writing have been almost non-existent for a while.

When I shut down SignalLeaf and had those 2 weeks of down time in July, I realized how completely unfocused I was with everything else.

And now, I have the time to fix that. Now, I don’t have three separate businesses that I’m trying to run. I only have my consulting and my screencasting now. And my consulting feeds my screencasting, to a large degree. So really, I have a much more focused business already.

But I still don’t have the kind of focus I want.

Finding Focus

In the next few weeks, I’m going to spend some more time thinking. The thought process is going to be aimed at creating new focus for WatchMeCode and DerickBailey.com. I am going to put a new emphasis on the direction that I am heading with JavaScript and all of the writing that I am doing. That new heading will be centered around architecture and messaging based patterns in JavaScript – both on the client and on the server.

These next few weeks will be used to determine how I want to approach this renewed focus. I’ll be setting goals for myself. I’ll be generating metrics that I want to capture. I’ll be looking at what I need to do in order to accomplish these things. I’ll be creating a singular focus for my work as an entrepreneur in the JavaScript space.

Resurrecting Architecture

Messaging and architecture aren’t new territories for me. I’ve got the RabbitMQ For Developers package which is all about messaging. But I’ve also got years of experience writing about architecture and messaging patterns for all kinds of applications, over at my old DerickBailey.LosTechies.com blog.

Architecture is what I did for many, many years – including JavaScript architecture. I brought messaging patterns to the world of Backbone.js when I built Marionette.js on top of it. I helped bring these same patterns to Windows applications and mobile devices when I built projects on those platforms, as well.

I want to bring these patterns of architecture, of scalable (not just large scale – scalable from small, all the way out) systems, and of messaging both in memory and across distributed systems, in to the world of JavaScript. This little language that could is finally doing it for more people than ever, and it’s about time the JavaScript community embraced the architecture it needs.

Join Me In My New Focus

I’m getting ready to refocus my blogging and screencasting, to center around JavaScript based architecture and messaging patterns, and I want you to come along with me. Clearly, you’re here now on my mailing list. You’ll get the blog posts as I restart this journey. You’ll be on the edge of what I am working on, already. But, there’s so much more to be found in WatchMeCode, already.

Take advantage of the 100+ screencasts and other videos on WatchMeCode.

This new direction will take a while to gain momentum. But I’m already moving. And I want you to join me in this new, better and more focused direction.

Categories: Blogs

Agile leads to technical debt?

Does Agile lead to technical debt?

The phrase "technical debt" was coined by Ward Cunningham in 1992.  Ward is known for a few significant things: wikis, CRC cards, and influencing Extreme Programming (XP).

XP was by far the dominant "lightweight methodology" when the Agile Manifesto was created.

So it seems rather odd to suggest that Agile leads to technical debt.  All the talk about technical debt came from Agile people.

Here's Ward talking about the history of "technical debt":

Here's a couple articles by Martin Fowler on technical debt:
Ward and Martin are signatories of the Agile Manifesto, which makes sense because they participated in creating it.

It's really ironic that people today might believe that Agile leads to technical debt.

But I can understand the belief.

XP is no longer what people typically think of when they think "Agile".  There has been a shift to Scrum and Kanban and management issues in general.  I can understand that people exposed to Flaccid Scrum might believe that Agile equates to poor technical practice.

The more controversial, though unoriginal, claim would be that XP practices lead to technical debt.  In other words, claiming that the community that developed and embraced the concept of being mindful of technical debt advocates practices that lead to it.
Categories: Blogs

Agile is for extroverts?

Is Agile for extroverts?
And given most programmers are introverts, is Agile just stupid?

Given that I'm an introvert and most people I've worked with are introverted, I find this question weird every time it's asked.

As long as you are building things for other people, you cannot be effective unless you engage with those people to understand the problem to be solved.  As long as you do not have perfect focus and infinite perspective, you cannot be effective unless you learn to work with other people in a close, collaborative way.

I will acknowledge that engaging with people in this way might initially feel uncomfortable.

But I'll suggest that you should be more interested in being effective than not being uncomfortable.  If  you can't make that shift, then yes, Agile is not for you.
Categories: Blogs

Agile is not sustainable?

Does Agile produce a working environment that is unsustainable?

Extreme Programming (XP) originally had an explicit practice called "40 Hour Week", which eventually became "Sustainable Pace".

Part of this was because of an intent to make software development humane; part of this was because people were interested in what was actually effective and not what just looked effective.  Working excessive, unsustainable hours is not effective.

As Ward Cunningham said, in response to a request to get a team to work more hours: "We would if it would help."

There are other practices that address sustainability:
I will acknowledge that there are some things that may seem like they are designed to increase unsustainability:
  • The use of the word "sprint"
  • Daily stand-ups
  • The continuous flow approach of kanban
  • Continuous Delivery
All the principles and practices designed for increased pace and speed can easily lead to unsustainability if you hold a particular mistaken assumption.

The mistaken assumption is that Agile encourages a one-way communication where a Product Owner tells a development team what to do rather than a n-way collaboration between everyone because that's just a better way to do software development.
Categories: Blogs

Guest Blog: The Value of Continuous Agile Retrospectives

Ben Linders - Tue, 08/04/2015 - 16:58
In this gust blog post on BenLinders.com David Horowitz, CEO and Co-Founder of Retrium, explores why you should do continuous retrospectives and how you can do them to establish continuous improvement. Continue reading →
Categories: Blogs

Run, Don't Walk, to Scale Agile

Rally Agile Blog - Tue, 08/04/2015 - 16:00

Rally customers have always been front and center at RallyON conferences — filling the audience and the speaking agenda with their experiences, knowledge, and ideas. But at this year's RallyON 2015 conference, our customers were so engaged they nearly blew up the conference app. Since their commentary did such a great job of capturing the essence of what we heard and learned at RallyON, we thought we'd share a few of the conference’s customer stories about Agile at scale — in our customers' own words.

The Seagate Story

Seagate is a leading producer of data storage solutions. To keep up in this industry, Moore’s Law alone dictates that you have to move fast. Seagate knew it needed a better way to predictably and reliably get products out the door, but it wasn’t initially familiar with Agile approaches.

At RallyON 2015, Seagate Agile coach Iky Chan and Rally Solutions Architect Andy Carlson co-presented a talk on Seagate’s journey from a waterfall shop to one that now assembles all 100+ members of its firmware group for release planning on a regular cadence.

Their story starts out describing how Seagate worked up from piloting a few Agile teams to selling leadership on the first big room planning event.

“What is big room planning? It's mid-range planning with all the people connected to a value stream. You need to get more than 7 plus or minus 2 people in a room together if you want to solve complex problems."

As the main ceremony for an Agile delivery group to successfully deliver on its release, big room planning naturally requires an investment of time, energy, and preparation. The Seagate talk did a great job detailing and demystifying the process of running a big room planning event. Chan even included a photo of her “big room planning suitcase.”

“Prep is required for a successful big room event.” "What’s in your big room planning kit? Big Post-Its, Sharpies, tape, markers, snacks . . . What else?” “Big room planning is often scary and intimidating — the first time! Each time it gets easier and easier.”

Halfway into their talk, Carlson and Chan put up a photo of several developers looking at a whiteboard full of stickies, an intimidating “wall of WiP.” 

The success of Seagate’s investment in Agile might be summed up in this quote:

“These guys used to work weekends. Since they started big room planning, not anymore. #bigroomplanning helped Seagate address bottlenecks and become more predictable.”

Several audience members noted during the Seagate story that big room planning isn’t valuable just for the work it produces, but for how it brings people together to collaborate:

“The outcome of big room planning isn't just a plan. It's a group prepared to execute on a plan.”

Chan closed the talk by exhorting the audience to “run, don’t walk” to the scaling agile booth in the lobby, where we demo’d how Rally’s new features can be used to improve your release planning.

(Read the Seagate case study or watch the video.)

The PayPal Story

When PayPal VP of Technology Kirsten Wolberg opened her keynote about PayPal’s Agile transformation, it made #BigBang a trending hashtag.

“If we didn't do a #bigbang the fear was we'd get all of the pain and none of the benefit because there were simply too many dependencies.”

As with many transformations, PayPal went all-in on change because its status quo had become untenable. A system of 15,000 people, left to its own devices, had devolved into bottlenecks and a lack of trust. There was too much effort on projects with not enough output, so the company committed to unraveling its problems and fixing them.

“Learning about the ‘why’ is important so that you can figure out the ‘what’ when it comes to transformations.” “Transformations usually are not about the development process. They are about mindset.”

Wolberg pointed out that executive support — a vital component of any transformation — isn’t the same as buy-in. Case in point: she heard,

"I trust you, but think you will fail spectacularly."

Executive support means leaders may not agree with every aspect of a transformation, but they will stand behind you to make change happen. She commented that leaders at every level need to play together for successful transformation: a mature leadership team has a willingness to look for and find problems, for example, then listen to advice about how to fix them.

As Wolberg describes in her keynote, PayPal mapped out a seven-month change agenda with four key pillars:

  1. Customer-driven innovation (CDI.) “Let’s figure out what the customer wants, not what we want.” This meant talking to customers, walking in the customer’s shoes, to understand their problems. This is in contrast to “executive-driven innovation,” which, as Wolberg said, has a greater chance of missing the mark since executives typically are not “in the same headspace” as customers.
  2. Core product operation model. PayPal implemented a product model centered around core product teams providing basic functionality (the “chassis”), with regional teams customizing for local needs. This approach was introduced to foster alignment and focus around core products (working on the right thing at the right time), while eliminating unnecessary complexity.
  3. Agile transformation. PayPal made a concerted effort to build Agile teams and ensure they had strong Agile practices. They re-organized teams — who previously had been siloed in 83 different product groups — around a vastly smaller set of value streams. In the process of assembling Scrum teams, they actually identified 200 “missing” people. And they gave teams ownership of the products, which fostered a sense of “having skin in the game.” Additionally, PayPal enlisted coaches in every region to provide back-up and support so teams could focus on delivering their work.
“Fragile (really bad agile) is a way to doom agility transformation.”

PayPal gave its Agile teams lots of flexibility, but asked every team to adhere to just two clear rules: follow a synchronized sprint cadence (start and finish sprints at the same time) and use a single, shared platform (Rally) for tracking work. There were knowing chuckles in the room as Wolberg described the fervor with which teams can get trapped in the "tool debate" — when the real challenge of an Agile transformation isn’t a tool at all, she pointed out, but resistance to change.

  1. KPIs. Key Performance Indicators are vital, explained Wolberg. Product and technology teams need to be accountable, and if you don't measure the value of your actions you won't know if they’re working. In particular, the company was keen to measure engagement — which it believes can lead to better solutions and better quality.

“KPIs help illustrate the right behaviours. Lip service isn’t possible if the right things are measured.”

There were nods around the room as Wolberg called out middle management as most resistant to transformational change.

“Permafrost, typically known as middle management, ice that never melts. Lol.”

She pointed out the importance of having open and honest conversations with development managers, to celebrate successes and identify opportunities, and called on us to use discipline in changing our own all-too-human behaviors.

“You have to hear something 7 times to remember it, and you have to do something 21 times to make it a habit. (Very true! )”

Wolberg ended her talk by summarizing some lessons learned at PayPal, and our customers in the audience had their own a-ha moments:

“The value of portfolio planning & roadmapping … Agility is a top-down mindset.” “Forming teams around the work/product is more effective than forming teams around the organisation chart.” "Fundamental agility disciplines and practices need to be built into the workflow; they are vital to moving forward well.”

Watch the PayPal keynote.

 

The Physicians Mutual Story

Physicians Mutual, an insurance company that’s been in business for more than 100 years, makes its headquarters in Omaha, Nebraska. So it seemed fitting when Physicians keynote speaker — Project Manager and Certified ScrumMaster Joan Bohannon — cited the famed Omaha businessman Warren Buffett near the beginning of her talk.

"Great quote: ‘Should you find yourself in a chronically leaking boat, energy devoted to changing vessels is likely to be more productive than energy devoted to patching leaks.’" “All hail the Oracle of Omaha!”

Like PayPal, Physicians told the story of a pilot turned #bigbang Agile transformation; but that wasn’t initially how its Enterprise Technology Group got started. The group had been using RUP and waterfall approaches before piloting Agile methods, and its first attempt at Agile adoption failed — for reasons that seemed all too familiar to some in the audience:

“The usual story ... No team, process or product integration … this is pain! Lack of integration creates bottlenecks and dependencies!” “[They] did Agile with one or two teams and one or two projects, but it didn't become sticky; Did Agile 101 training, but not role-based training." “Limited roll out = limited results.”

So the group took a deep look at how it was doing things, and decided to make some serious changes — cue Warren Buffett’s advice to get a new vessel rather than patch the leaks. At Rally we often talk about transformational change through platform, process, and people, and Physicians set out to improve all three of these areas.

Platform. Like many growing companies, Physicians had integrated various technologies in an effort to harness its growing complexity — only to end up with a vast (and complex) catalog of tools. When it overhauled its catalog and settled on Rally as its central hub, Physicians went from 23 different tools down to 5, at a savings of $300,000. “We looked at many tools,” said Bohannon, “but we quickly realized that Rally was the only organization that could provide training and coaching as well as the platform we needed.” Standardizing on a single platform had other benefits, too:

“As soon as the software got in the door, people were so excited about it that they didn’t want to wait for the pilot. that’s when we realized we should be going with a big bang approach.”

Process. "Boy, did we have process,” said Bohannon. “Click on any one of these and you'll get more process," she said, standing in a front of a slide with a spider web of interconnected people, departments, and requirements.

Physicians actually reviewed all of its legacy processes and got rid of the ones that weren’t working, leaving them “just enough process to be successful.” With the Rally platform in place Physicians can plug directly into its other four tools, further minimizing process maintenance and context-switching.

“Rally integrations streamline processing!” “I envy having five tools.”

People. Unlike the first time around, when it only did “intro to Agile” courses for some pilot teams, Physicians was keen this time to include comprehensive and role-based training — as well as Scaled Agile Framework® (SAFe®) training to help them implement and manage the transformation. “We trained everyone,” said Bohannon. “Project managers, testers, developers … and we coached some in-house coaches to provide ongoing support.”

“Very impressive investment in people!”

With the platform, process, and people changes in flight, Physicians began to use its Rally data for conversations about performance and collaboration. Rather than seeing metrics as a weapon or punishment, the increased transparency helped teams drive important discussions — “the why behind the what.”

“Early conversations allow course corrections. Late conversations can become screaming matches!” “Transparency for team health checks - what a bonus!” “Rally helps provide transparency for end to end process improvements. Love this!”

One of the early conversations at Physicians was about estimates, points, and timesheets. Physicians made an effort to move away from timesheets and learn to estimate and plan based on points, instead. At a business level, cost by points turned out to be more accurate than timesheets — whose value was questioned by many in the audience:

“Timesheets are a drag! Wow!” “??? Could this ever work for our organization ???”

Physicians uses Rally and Planview for its portfolio planning and management, and Physicians Program Manager and co-keynote speaker Thomas Hall described how its product owners and portfolio managers plan and track progress — from the team level to the program level to the portfolio level.

Hall explained that portfolio management is hard, but critical for enterprise success. A “Business Council,” comprised of senior executives, is charged with setting strategic priorities for the company. Portfolios steer the business to the highest-value priorities; programs align the development work to those business priorities; and delivery teams plan and track their work according to program direction. Feature definition is key to successful prioritization. Product owners gather as a team to review and assess. When estimates change, that information rolls back up the hierarchy so they can re-evaluate the plan.

“Business council is the way to go! Keep the enterprise focused! Realise the value stream! Love this!”

Because everyone in the group — from developers to executives — is using the same platform, they can all see progress in realtime and make necessary adjustments. Teams have access to important information about prioritization and capacity, while managers can identify risks and do more accurate planning.

“Would love to get out of Excel and PowerPoint and into Rally.” “My program managers are not looking at this sort of detail. It would really up the game. A cool view to assess the health of the backlog.”

In addition to decreasing its tool footprint and maintenance costs, Physicians’ Agile transformation has yielded other substantial benefits: the Enterprise Technology Group has increased its major releases from four to six per year, and now delivers at the end of every iteration — nearly 1,000 stories per year — without waiting for a major release. More importantly, given it’s the group that maintains the entire company’s business-critical systems, it has improved its ability to respond faster to market demands and is considered a trusted, predictable partner for the business. Customers sure loved the outcome.

“Great insights from actual practitioners!” “Big Bang approach to agile transformations hurts my head, but I'm thinking it through …” “Love the hard conversations this will evoke!”

Watch the Physicians Mutual keynote or read the case study.

Want more stories? Check out some of our other scaling Agile customer stories from RallyON, including another perspective on Physicians Mutual’s transformation, “What Pilot? Physicians Mutual's ‘Big Bang’ Approach“;  “Scaling Scaled Agile: Lessons Learned at UnitedHealth Group” and “Heartland’s Scaled Agile Journey.

 

Rally
Categories: Companies

10th Annual State of Agile Survey is Open!

Agile Management Blog - VersionOne - Tue, 08/04/2015 - 14:30

300x250It’s hard to imagine that we’re celebrating the 10th year of the State of Agile™ survey! The annual survey has become the largest, longest-running, and most comprehensive survey serving the agile community.

Last year nearly 4,000 of your peers shared what they’ve learned through their agile experiences. The survey gives agile software professionals around the world the opportunity to provide insights on a wide range of agile topics including the benefits of agile, top tips for scaling agile, how to measure agile success, and the most popular agile project management tools. This year we will be conducting an even deeper analysis of the trends over the past 10 years.

To help celebrate the 10th anniversary, VersionOne is giving away 10 Apple Watches in a random drawing in each of the 10 weeks that the survey is open. The survey, which takes about 10 minutes to complete, is open until Oct. 2. The full report will be available in early 2016.

For the past nine years, the results from the State of Agile survey have been helping organizations realize the benefits of agile faster, easier and smarter. Help the agile community make the 10th annual State of Agile survey the most valuable report yet!

State of Agile is a registered trademark of VersionOne Inc.

Categories: Companies

Knowledge Sharing


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