Feed aggregator

Test Automation Patterns: Issues and Solutions

Agile Connection -

Automating system level test execution can result in many problems. It is surprising to find that many people encounter the same problems yet are unaware of common solutions that worked well for others. These problem/solution pairs are called “patterns.” Seretta Gamba recognized the...

Lightning Strikes the Keynotes: STARWEST 2014

Agile Connection -

Throughout the years, Lightning Talks have been a popular part of the STAR conferences. If you’re not familiar with the concept, Lightning Talks consists of a series of five-minute talks by different speakers within one presentation period. Lightning Talks are the...

Discover Agile: A New Way to Work

Rally Software - Agile Blog -

In an interview with SD Times a few days ago (“Don’t do agile, be agile”), Rally VP of Engineering and former agile coach Ryan Polk called out what is, for many companies, the elephant in the room: if you’re not seeing the results you’d hoped for with agile, you might be doing it wrong.

(Flickr, CC)

As Ryan explains it,

“Human behavior … tends to gravitate toward the easiest practices, not the best practices. Agile is a set of hard practices. They actually take discipline. They take understanding how your teams are working and evolving.”

If your organization is suffering from unrealistic plans, unstaffed priorities, quality issues, customer dissatisfaction, delayed delivery, or low morale, then you’re ready for a new way to work. If you think you’ve evolved toward the easy practices instead of the best, it might be time for a level-set. And if you’re new to agile, it might be time for a tutorial on the basics.

Agile, done correctly, promises a range of benefits: faster time to market, increased productivity, fewer defects, cost savings, and better employee engagement. We can help you get started with a strong foundation of disciplined practices, executive buy-in, realistic goals, and motivated teams. Join our Discover Agile webinar on Tuesday, September 22, at 11 AM MDT. You’ll come away knowing:

  • How agile, Lean, and Scrum really work
  • Where agile differs from traditional methods
  • The business benefits agile can deliver
  • Ways to get started with agile


Register now.

Rally

Defining Acceptance Criteria for Agile Requirements

Agile Connection -

Acceptance criteria can be helpful in expanding on user stories in order to capture requirements for agile projects. However, acceptance criteria should not be a route back to long, detailed documents, and they are not a substitute for a conversation. This article tells you how and when acceptance criteria should be written and employed.

Lead the Change: Learn to Drive an Agile Transformation

Rally Software - Agile Blog -

Isn’t it fun to think about a future that includes driverless cars? The technology behind them is pretty impressive, but it isn’t quite where it needs to be to take over for humans. And in the meantime, we humans continue to be fallible creatures. We need instruction and practice to drive well, and even then, we sometimes get off-course or hit obstacles along the way.  

 (image: Flickr CC)

You know what’s even harder than driving a car? Driving an agile transformation. While agile principles may seem simple to understand, they can be complex to implement at scale. Changing an organization’s processes, practices, and culture takes knowledge, discipline, and motivation. Especially in large companies, guiding a scaled agile implementation can feel like steering a battleship with a joystick. This is why all successful change initiatives need great humans to drive them.

The Cred to Create Change

We can train you to be a great driver. Our SAFe® Program Consultant (SPC) workshops will give you the confidence and know-how to lead an enterprise agile transformation. This four-day, intensive training will teach you how to harness the Scaled Agile Framework®, so you can accelerate change within large organizations and unleash the power of agile.  

You’ll learn …

  • The application of Lean, agile and product development flow principles for better productivity, quality, time to market, and employee engagement
  • How to apply the Scaled Agile Framework, as well as how to teach and certify others in SAFe
  • Certified leadership skills for unlocking people’s intrinsic motivation and leading a transformation
  • How to identify value streams and organize Release Trains around them
  • How to prepare the organization and its teams to launch Release Trains and run the first release planning
  • When to interact at key program touchpoints, to help "keep the train on the tracks”

… Plus a whole lot more.

Who Should Be an SPC

Our SAFe Program Consultant training and certification is a great course for internal agile change agents or external consultants. It provides the training you need to validate and implement your knowledge of agile programs, program portfolio management, agile architecture, and SAFe, so you can launch and steer an enterprise change initiative.

Your SAFe Program Consultant Trainers (SPCTs) are among the industry’s most experienced, hands-on coaches. They work regularly with a broad range of companies in applying their agile skills, honing their knowledge of leading-edge techniques, and identifying and resolving some of the most difficult organizational challenges. (Keep reading for a fact about our trainers you probably didn't know.)

Get Started

Rally’s Agile University is offering SPC training and certification courses in four cities around the world, over the coming months:

  • 15–18 September: Singapore
  • 20–23 October: Dallas
  • 10–13 November: Raleigh
  • 17–20 November: Sydney

Visit the AgileU website to get the details.

Do you want to help other great humans build great organizations? Start by learning to drive, steer, and lead agile transformations. Sign up for our SPC training and certification course and get the skills you need to drive change with the right kind of impact.

P.S. Did you know that there are fewer than 25 SAFe Program Consultant Trainers, or SPCTs, in the whole world, and five of them work at Rally?

Rally

Reducing Technical Debt

Scrum Alliance -

How do organizations balance releasing the best product against meeting time-to-market need? In other words, what's the best way to deal with technical debt?

Swisscom: Disrupting the TV Industry with Agile

Rally Software - Agile Blog -

Chances are, you or someone you know has “cut the cord” recently — canceled your cable TV subscription service in favor of the alternatives, like a set-top box, rabbit ears, streaming services such as Netflix and Hulu, or Internet-delivered media. Here in the United States, one survey found that more than eight percent of cable TV subscribers had cut the cord last year.

One thing you may not have considered is how this cord-cutting, multiplied by the thousands, is radically disrupting the cable and communications industry.

Swisscom, Switzerland’s leading telcomm company, was mindful of fast-changing industry trends when it decided to insource the development work for a new IPTV (Internet-delivered television) initiative. The company wanted to get its Swisscom TV 2.0 service out to the marketplace quickly, before its competitors; however, its organizational structure and culture were not set up for agile delivery.

Laying the Groundwork

Bringing the development work for the IPTV initiative in-house was just one of many steps the company took to transform itself: it also built strong, cross-functional trust and transparency by co-locating developers with business owners, DevOps, and vendors across near-shore teams in six countries. Much of this groundwork already was laid when the company discovered agile a few years ago.

“We simply did what made sense for us, and we figured it out as we went along. Only later did we realize that our efforts overlapped with existing practices for agile at scale.”

- Simon Berg, Agile Program Manager, IPTV Engineering

Scaling Up

With support from Swisscom’s head of TV development and technology, the IPTV group adopted and scaled agile approaches: it implemented the Scaled Agile Framework® (SAFe®) and took advantage of Rally Unlimited Edition’s performance in tracking work at the portfolio level.

“We chose the Rally platform for its portfolio-level management capabilities. No other solution could link strategy to execution across 12 teams, with rolled up visibility of multiple programs.”

- Simon Berg

Launch Time

Swisscom launched TV 2.0 in 2014, and in just over a year racked up more than half a million subscribers — that’s more than 15% of all Swiss households. Meanwhile, Swiss cable companies have lost 98,000 TV customers in the past 12 months.

Swisscom’s agile transformation played a key role in the initiative’s success. The company cut development cycles from 12 months down to 3-6 months, and the teams’ use of agile testing and validation approaches improved quality and minimized rework. Perhaps most importantly, Swisscom didn’t just deliver on-time: it delivered the right product for the market. Being agile allowed the company to respond to shifts in direction and keep up with fast-changing consumer demands.

“Ultimately, the culture and the people are how we innovate and win in an industry that is constantly being disrupted by new technologies.”

- Simon Berg

Read the entire Swisscom case study, then learn more about big room planning and Rally’s agile at scale platform.

Rally

Product Owner, Product Manager, or Project Owner?

Agile Connection -

If you really want to get the benefit of Scrum, you have to make the mind shift to product ownership, not project management or project ownership. The product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer.

The magic of pi for project managers

Alistair Cockburn -

An experienced project manager told me he multiplies his developers’ estimate by π.
“It’s a natural law,” he said.
I have since found that π, π^2, and √π are all important magic numbers for project managers .

  • Multiply by π for small, known teams, doing a new job,
  • by π^2 for unknown teams,
  • and √π for known teams who have already started, know their work and have a good track record.

Here’s an example from real life:

I was asked to come in and be technical coordinator on a project of 3 people who were in phase 2 of a 3-phase project. They had said the project would take 15 work weeks.

(In my world, this small of a project does not need a technical coordinator, it is a “do it and go home” size of a project)

I started asking questions and got strange answers back, indicating that this might not be actually just a 15-work week project. We decided to hold a proper estimating meeting (I had not yet run across the Blitz Planning technique at that time, sadly). On the way in, I was describing to the sponsor about the magic of π^2 on estimates, not really thinking about it, just chatting. When we finished the session, the estimate came out to a whopping 130 work-weeks! Yikes! (and imagine the fun discussion that followed, with the various project funding groups!). As we walked out, she said, “130 work-weeks about 9 times 15 work-weeks. How did you know that?” I said, “I didn’t, it’s just one of those magic numbers.”

About 4 months later, she did some more re-estimation, and said to me, “I can’t keep multiplying their estimates by π^2, what should I do?”
I replied, “They are in steady-state now, working well along. Just multiply by √π at this point.”
She did, and they did.

The project came in at about 190 work-weeks, and was considered a “success”, because they got to the final estimate well ahead of the end of the project, which was a first for them.

I’ll add the logic as to why these three numbers work as a 2nd installment to this post… stay tuned.

Part 2. Why does this work

OK, to be honest, I don’t know. That’s the magic of magic numbers. But I’ll load up some observations and see if they make sense.

You move at 1/3 the speed you think you will.

Did you ever make a list of things to do on Saturday? You know

  • take dog to vet
  • buy replacement thimtwiddlle for the doohickey
  • take kids to visit auntie
  • clean the basement
  • put the back of the garage into order
  • vaccuum under the kids’ beds
  • read more of Lost in a Good Book
  • get in-box to zero
  • et cetera

And you run around all day like a maniac, and at the end of the day you moan, “Gag! I didn’t even get HALF my list done?”

Next time this happens, take another look: Did you get 1/3 of the list done?
If so, that was a good day. Congratulate yourself.

It’s very often the case that we move / accomplish at about 1/3 the speed we think we will.

There are often 3x as many tasks inside a new project as you can visualize

Imagine you make a list of all the things you would have to do to get a particularly complicated piece of work done.

  • I did this once when we were considering adding a little bathroom all by ourselves. The list of tasks as easily 3x the list we expected.
  • It is not too different to going to the grocery store without a shopping list — you get to the checkout counter, and sure enough, you’ve managed to buy 3x the amount of stuff you expected, 3x the cost.
  • Or write a description of how to make a meal or something for your teenager, and see how many elements you normally do without thinking you left out

The thing is, when we think about things to do, we gloss over many of the small details, forget the setting up, the cleaning up afterwards, movements of transition.

For many (not all) things that we do, especially things we haven’t done before, we only manage to list about 1/3 of all the things to do.

Off by 3 on speed, off by 3 on size, and you’re off by 9. π^2.

In the project example up above, this team of experienced developers left out gathering the requirements, meeting with the other team, testing, and many other things. They only wrote the estimate for “programming”. Off by 3x. Then, once they looked closely at the tasks and thought in more vivid terms about doing them, they realized they would take longer than they originally imagined. In fact, a lot longer, like 3x.

That’s π^2.

But what about long-term, steady state? You can’t keep multiplying everything by π^2! Surely there is some learning?!

Yes, indeed. The key to understanding √π is the small distractions of daily life.

The same project manager who told me the magic of π later, when discussing utilisation quota for consultants and employees, told me, “I never count on a person being productive more than 60% of the time. There are just too many small things happening during the day.”

hmmm if something were scheduled to take 1 day, at 60% efficiency, it would end up taking about 1.7 days.
√π is 1.77.
Not bad.

So now imagine a team is rolling along nicely. They understand their job and their normal pace. They are still likely to forget about all those little things, the phone calls, the meetings, someone dropping in to ask questions, having to reboot their computer or install a new program…. so, they will still estimate at a full pace, not one recalibrated to account for all the little slowing down items that happen during the day. And they will be off by √π

Here’s the graphic for all the above:

Postscript: It took a long time before I noticed one interestinng little detail about the project described at the beginning. It came in at 190 work-weeks, after we had carefully examined it for 130 work weeks. 190/130 is 1.46, or very close to √π!

That’s magic.

Take a look and see how these thoughts all fit into your day(s).

How ADLM Gobbles Up DevOps

VersionOne Agile Management Blog -

 

 

 

 

 

In the 1980’s and 90’s, the business software landscape was dominated by a diverse list of cutting-edge companies such as Best Software, i2, Brock Control Systems, Mapics, Ross Systems, Infinium, FBO Systems, Manugistics and MSA (of course I could go on and on). Now long gone, these and hundreds more really great companies have been gobbled up or rendered obsolete by the rising class of ERP giants. In this article I’ll explain why history will repeat itself leading to the extinction of most DevOps tools as leading ADLM platforms continue to assert their dominance across the diverse software development and delivery automation ecosystem.

History Informs Our Future and The Evolution of ERP

You already know that for the past twenty years, most companies have leveraged some form of ERP system to manage virtually every core business processes. One benefit of this tightly integrated solution is a powerful inter-functional data flow that enables corporate agility and provides the highest level of visibility. This super-integrated architectural model has become the standard adopted by virtually every enterprise around the globe. What you may not know is today’s “ERP model” is the result of four distinct evolutionary generations that I believe help predict the next major evolution of automated software delivery.

Phase 1 – Automation
Enterprise Information Systems (EIS) – In the 1960’s, early automation systems were developed to support important individual business functions such as general ledger, inventory management, billing, payroll, etc. These systems were architected completely independently of each other and added little value to the enterprise beyond their narrow scope.

Phase 2 – Core Data Model
Manufacturing Resource Planning (MRP) – Then in the 1970’s, the idea of a master production schedule was devised so that a few of these isolated systems could gain greater visibility into future inventory and product requirements of the organization. The big idea behind the master production schedule was the creation of an open data model that could be leveraged by other systems impacted by the manufacturing production schedule.

Phase 3 – Expansion
Manufacturing Resource Planning II (MRP II) – In the 1980’s, software vendors began to build and sell off-the-shelf packages that promised “best of breed” process design. These solutions provided tightly integrated versions of the key manufacturing processes required to produce products.

Phase 4 – Business Process Domination
Enterprise Resource Planning (ERP) – Finally, in the 1990’s, business software vendors expanded well beyond the manufacturing scope by creating highly-integrated solutions that now cover just about every standard business function imaginable. These systems leverage a unified data model to dramatically improve visibility, consistency, accuracy and planning capabilities enterprise-wide.

What Does ERP Have To Do With Automated Software Delivery?

The evolution of ERP has taught us how natural pressures forced the creation of a unified and comprehensive “business data model” spanning the entire enterprise. Those software vendors with enough influence to dictate that data model were the ultimate winners in the ERP space.

In the very first generation of ERP (EIS), software was leveraged to deliver a high degree of automation to many business processes that were previously manual. Over time, it became clear that these newly automated processes were interconnected and the evolution towards a tightly integrated and unified data model was underway. The business objective that fueled each successive generation outlined above was the need to design more efficient business processes that increased organizational visibility and agility.

As Marc Andreessen famously said in 2011, “…more and more major businesses and industries are being run on software and delivered as online services—from movies to agriculture to national defense.” (Why Software Is Eating The World). That statement resonates even stronger four years later. Today, virtually every corporate organization is seeing the familiar pressure to deliver software more efficiently and reliably. If history is indeed our guide, any highly fragmented and/or isolated process required to deliver incremental software change will face mounting pressure to be merged into an integrated end-to-end enterprise-grade platform that can deliver improved cross-functional visibility with even greater efficiency.

Why Application Delivery Lifecycle Management Will Win

In my view, there are really only two broad solution categories in the realm of automated software design and delivery – Application Development Lifecycle Management (ADLM) and the catch-all term DevOps (which I’ve hijacked here to describe any other type of process automation that assists the software delivery process).

DevOps tools are often narrow point solutions that have sprouted from open source projects, in-house development or commercial vendors. Organizations rely heavily upon a diverse collection of these DevOps tools to help document, validate and automate a steady flow of software change along its path to end-users.

Here’s the problem DevOps tools are beginning to face: Like the EIS systems of the 60’s, fragmented DevOps tools have little or no visibility into the overall end-to-end process; however, they do generate lots of important data that is often locked away and isolated. This isolation creates a clear barrier to efficiency, visibility and agility across the software delivery process. Because of the limited function each individual DevOps tool performs, none have the gravitational pull required to define the larger data model. As comprehensive enterprise software delivery platforms emerge elsewhere, standard DevOps tools will face ever-increasing pressure to fold inside them.

Currently, Application Development Lifecycle Management (ADLM) solutions provide a platform to manage development projects, team resources and all manner of development activities. ADLM platforms also contain the “master production schedule” for every development initiative – past, present and future. The data contained within ADLM is now at the core of a quickly emerging software delivery data model and leading ADLM vendors are expanding their footprint pwell beyond traditional use cases. When it comes to ownership of this software delivery data model, I see no other solution category across the entire ecosystem with enough enterprise clout to pose a serious challenge to leading ADLM vendors.

Unified Software Delivery Platforms Are Already Emerging

Each of the five current ADLM leaders (according to Gartner’s most recent Magic Quadrant) are now racing to bring to market an enterprise software delivery platform that integrates many key DevOps capabilities.

Here’s my two cents on each…

The Giants in the space – IBM and Microsoft both have plenty of muscle and IP today. Clearly both are moving down the path toward a comprehensive software delivery platform. IBM acquired DevOps vender urban{code} several years ago and is hard at work building their developerWorks platform. Seemingly everyday, Microsoft is adding some kind of DevOps capability into its Visual Studio product suite. Still, I don’t see either vendor gaining much traction outside of their traditional (albeit very large) customer base. Perhaps more importantly, neither seem to have bonafide credentials within the super-influential agile development community and I believe this kind of street-cred (at least for now) is a must-have to dominate this space.

Atlassian does enjoy wide support among the agile community and no doubt has the broadest adoption footprint of any of the current ADLM leaders. Atlassian is in a strong position to mount a serious threat. However, Atlassian’s core product (JIRA), is widely believed to lack heavy-weight depth in the ADLM feature spectrum and it is often implemented as a departmental or “team tool”. They’ll have to develop deeper strategic planning and multi-team project capabilities to beat the rivals.

This May, software giant Computer Associates announced a definitive agreement to purchase ADLM heavyweight Rally and its agile development platform. In its announcement, CA said it intends to leverage Rally’s capabilities to “complement and expand CA’s strengths in the areas of DevOps and cloud management”. With the crucial addition of Rally, CA is now in a strong position to assemble its diverse capabilities into a single unified and enterprise-caliber software delivery platform. Now… can they seamlessly integrate all of the pieces-parts into a cohesive solution with a unified data model? If so, how long will it take?

Finally, I believe VersionOne may have a slight edge over the other ADLM vendors in the race toward a unified software delivery platform. I may be a bit biased because of my direct involvement in a joint project currently underway – none the less, here are four reasons why they will absolutely be a dominant force to recon with:

Vision: Robert Holler, VersionOne CEO, is clearly buying into the “enterprise software delivery platform” vision. He and his team have a well thought out strategy and they are actively executing against that strategy.

DevOps Automation: VersionOne has partnered with ClearCode Labs and both teams have been hard at work integrating ClearCode’s Continuous Delivery Automation framework into the VersionOne core product. This integration provides VersionOne the ability to orchestrate virtually any DevOps tool or platform and (just as importantly) incorporate all related data across VersionOne’s product suite to fee its quickly expanding data model.

JIRA Integration: VersionOne has just announced a tight integration into the JIRA platform. This integration will give them the ability to fold fragmented JIRA installations across the enterprise into the unified VersionOne platform providing a more strategic and enterprise-grade solution.

Availability: VersionOne’s automated delivery platform is available now and they are demonstrating their comprehensive solution to the eager agile community this week at the sold-out Agile2015 conference in Washington, DC.

Summary

The top 5 ADLM vendors are already well on their way toward developing enterprise-grade software delivery platforms that will consume many of the current “DevOps” automation solutions. Soon, development organizations will benefit from a comprehensive platform that can deliver increased efficiency, visibility and agility when compared to the heterogeneous solutions that have been cobbled together today.

About the Author

Dennis Ehle, is a pioneer and thought leader in continuous delivery automation and agile delivery methodologies. Dennis is passionate about helping agile teams dramatically reduce the transaction cost associated with delivering incremental change. His company, ClearCode Labs, does just that by helping organizations continuously deliver high-quality software releases more frequently merging proven methodologies with empowering tools and technology. Twitter: @DennisEhle

Article originally posted on DevOps.com

Screechingly obvious code

Alistair Cockburn -

Back in the very late 90s I wrote on Ward's wiki the entry Screechingly Obvious Code. That entry was prompted by reading one of Kent Beck’s articles on programming, where he had described the State pattern. His code was all clean and tidy by usual standards, but somehow I couldn’t get comfortable with it for some reason – the naming was still too obscure for me.

Then I watched people find and fix bugs in a hurry, and it became clearer to me —- they needed function/method names that really shouted out what was about to happen in there.

The contents of the Ward’s wiki entry go like this, slightly reformatted and few sentences with example code added:

Times used to be when people who were really conscientious wrote Squeaky Clean Code. Others, watching them, thought they were wasting their time. I got a shock one day when I realized that Squeaky Clean Code isn’t good enough.

I was standing behind two people who were working their way through a bug list sent up by the testing group. Instead of helping them work, I started watching their movements (this was Smalltalk, 1995, many browser windows on the screen). They would look through the method where the error had been caught, and guess at which called method contained the error. They called up the browser for a class, scanned the method list and opened a method. They looked at the method to see whether it was the place they were going to type in their fix. When it turned out not to be, they looked for what other method could be the one? They averaged 15-45 seconds per method as they went down through the code and across the methods in the browser list. At each point, they were looking for, is this the place I type my fix, or where does it point to next?

It occurred to me that where they went down a dead end was because the method’s contents did not match its name. These people were basically looking for a sign in the browser that would say, “Type in here, buddy!”

That’s when I recognized that they needed ScreechinglyObviousCode.

At the time, it was considered an OK thing to do to have an event method,

doubleClicked
do this
do that

i.e., inside that method do whatever needed to be done.

That would be allowed under Squeaky Clean Code.

However, in Screechingly Obvious Code, it wouldn’t, because the method name doubleClicked only says that something was double clicked, and not what would happen.

Let’s say that it should refresh the pane or something. There should therefore be a method called refreshPane, and doubleClick would only contain the one line: self refreshPane.

doubleClicked
refreshPane

So if you were tracking down what happens on a double-click, you’d naturally spot doubleClicked, and opening it you’d know the pane gets refreshed. And/But/Further, if you were having trouble with pane refreshes, you wouldn’t have to go and dig out that pane refreshes (maybe also) happen after a double click, you could just go and read

refreshPane
do this
do that

Exactly that was happening on this project. The people fixing the bug knew there was a problem refreshing the pane, but had to dig to learn that refreshing the pane was being done inside doubleClick. It would have saved them much effort if the method refreshPane was clearly marked in the method list in the browser, so they could go straight there.

I learned, from that afternoon, not to put behavior into an event-handling method, but for such a method to call out a behavior-containing method with the appropriate name. The reading of the code is then, simply: “When a doubleClicked event occurs, refresh the pane” rather than “When a doubleClicked event occurs, do all this stuff, which, by the way, if you read carefully, you will notice refreshes the pane.”

At that point I started looking for ScreechinglyObviousCode (hint: be sure to use “IntentionRevealingNames”). XP, of course, encourages this. Personally, I think the StatePattern violates ScreechinglyObviousCode and makes for pretty obscure code, but I don’t have the energy to revise it and publish… maybe someone else will take up the challenge. — AlistairCockburn

Anyway, that was my posting back then, and James Shore fortunately picked up the theme in his article Quality with a Name and his book, Art of Agile Development.

Then today, I saw a reference to Bob Martin’s codingtips (probably from his new book Clean Code which I’m itching to take a look at), and lo and behold – there’s almost the same example, except he ran into it by looking for code duplication.

Bob describes it under his particular conditions, but basically, he had two functions, slim_to_ruby_method(method_name) and to_file_name(module_name), both of which used letter-for-letter identical code, that just accidentally did the same thing … convert a CamelCase word to lower case with ’_’ between words (e.g., moduleName -> module_name).

In the article, Bob works out that they aren’t really duplication but they are really duplication, and he generates the same answer as if he had been running the Screechingly Obvious Code argument through his head … that is, that the code was REALLY identical, in that it was quite intentionally doing the same thing: camel case to underscore between words; and that the calling methods intentions were different – i.e., one was converting method names, the other module names.

The Screechingly Obvious Code result looks just like above, and just like what he produced, and here I quote his code:

def slim_to_ruby_method(method_name)
camel_to_underscore(method_name)
end
enddef to_file_name(module_name)
camel_to_underscore(method_name)
end
def camel_to_underscore(camel_namme)
value = camel_name[0..0].downcase + camel_name[1..-1]
value.gsub(/[A-Z]/) { |cap| ”_#{cap.downcase}” }
end

And those tell the reader both what each function is supposed to do and what it really does. It gets rid of the duplication where the duplication is supposed to gone and leaves things apart where they are supposed to be left apart.

Nice.

Decisions in Progress and 20,000 Reasons You Should Care

Rally Software - Agile Blog -

At a large big room planning (BRP) event run by one of our customers recently, between 400 and 500 people spent two days planning their next 12 weeks of work. The stakes were high, as the health care product they are racing their competitors to deliver must go live by January 1st.  Rally talks about big room planning as the “secret sauce” of agile at scale, and one of the key reasons it's so powerful is because it exponentially cuts down on decision-making cycle time. In short, lots of decisions get made. Fast.

I worked with one of the customer's Agile Release Trains (each Train consists of a number of associated teams) over these two days to prioritize and plan their upcoming work. It’s a tiring two days: not because of the physical demands so much as the constant collaboration, communication, and thinking required between and across trains. We’re often not used to working at that pace in our regular office jobs. Traditional planning of this type — usually document-driven, over an annual cycle— is fundamentally flawed because the teams and stakeholders are not collaborating and making decisions in realtime. Why is this a big deal? Because decisions in progress are a form of WiP (work in progress) and, in short, too much WiP is harmful.  

 (Flickr Creative Commons)

Like all WiP, decisions in progress (DiP) should be completed as soon as possible: ideally you should reduce your cycle time for making decisions, reduce the batch size of your decisions, and increase their frequency. If your DIP is high or out-of-control you’ll see the same problems as with high WiP: bottlenecks, long lead times, long feedback cycles, and increased defects, to name a few.

What does this have to do with big room planning? Well, it’s an event where 500 people make a lot of decisions over the course of two days. Let’s use some simple math: If 500 people each make 20 decisions per day (a conservative estimate), that’s 20,000 total decisions made during the event, with an average cycle time of around one working day. In my view, that’s a good return on investment. Divide the cost of running a big room planning event by the number of decisions made and it will equate to around the price of a good coffee per decision. (Having unlimited coffee at this kind of event is one more good decision, as it pays for itself.)  

If the math doesn’t convince your stakeholders, then look at your company’s current decision-making ceremonies: these may be monthly meetings, stage gates, approval meetings, etc. How many decisions get made? Some, sure. But 20,000? Probably not. What’s your average cycle time for making decisions? Maybe some decisions are made in the meetings; but if your decision is in the queue until the next meeting —  the following month — that’s a 30-day DiP cycle. Lean experts like Mary and Tom Poppendieck back up the high cost of DiP to an organisation through studying processes’ value-add versus non value-added time. Often the latter exceeds 80% through delays and hand-offs, many of which relate to decisions in progress.

A large financial institute I recently visited described the ceremonies used by its Agile Release Train. They initially started off with a daily Scrum of Scrums meeting, with a view of reducing the frequency once the teams became more mature. However, they derived so much value from reducing decision-making cycle times that they agreed to keep it on their daily schedule. How many teams in your company vote to meet more often than required because the meeting proves its value?

So: treat your DiP like WiP. Aggressively reduce it, shorten your cycle times, improve the flow of DiP, and improve the quality of your decisions through realtime, face-to-face collaboration. You can start by identifying three upcoming decisions in your area of the organization (e.g. small, medium, large) and how these will be handled. Brainstorm with your team about what you can do to reduce the DiP cycle time for each decision.  

In the time it took to write this blog, 1,000 decisions were made in the aforementioned big room planning event. In the same time period, how many decisions were made about your company’s next release?   

Suzanne Nottage

The Scrum Daily Standup Meeting: Your Questions Answered

Agile Connection -

The daily standup, or daily scrum, is a short meeting the team uses to briefly communicate work commitments with each other. Dick Carlson answers some questions that agile teams, management, stakeholders, and those who are thinking about transitioning to agile commonly have about these daily standup meetings.

Test Automation in the Agile World

Agile Connection -

After decades of talking about test automation, the agile movement suddenly seems to be taking it seriously. You might be wondering what all the buzz is about. Sanjay Zalavadia talks about why test tooling is suddenly so critical, when teams should think of automating, and how to bring the change so that your team will embrace it.

Agile 2015 Conference Highlights: Saluting Enterprise Agility

VersionOne Agile Management Blog -

I am just returning from a fantastic week at the 2015 Agile Alliance Agile conference held from August 3-7 just outside Washington D.C. and wanted to share some highlights with those who were unable to attend. This conference attracts international interest and was attended by over 2300 participants, including both experienced practitioners looking to refine their game, as well as novices seeking to join in and reap the powerful benefits of this mainstream set of values and principles that we call “agile”.

As a title sponsor, VersionOne featured the latest innovations in its Enterprise Agile Platform to help enterprises succeed with scaling agile, our support for the Scaled Agile Framework® (SAFe®), and new capabilities such as TeamSync™ for JIRA.

The industry focus on DevOps continues, as do discussions on successfully navigating barriers to change and scaling successfully.  VersionOne featured a unified DevOps solution showcasing demonstrations of the new ClearCode integration that enables an automated visual flow of change throughout the software cycle from discovery through final delivery.

 

 

 

 

 

 

 

 

 

The VersionOne theme, “Enterprise Agility:  Revolutionizing How Teams at All Levels Work Together,” echoed well with the conference sessions and discussions focusing on scaling agile across enterprises.  At VersionOne, we know that revolutionary change, change that really matters, can only be achieved by people working together at all levels.  Conference sessions and experience reports discussed keys to successful transformations, including the importance of executive support and addressing the underlying culture and the soft skills needed to succeed.  Conversations at the VersionOne booth included Dean Leffingwell, the creator of the Scale Agile Framework® (SAFe®), sharing insights around scaling agile.  Jeff Sutherland, Scrum co-originator, was also spotted sharing insights at the booth as well.

VersionOne toasted 10 years of the State of Agile™ survey, the industry’s longest running survey, by serving champagne during the Wednesday evening vendor show.  A very popular tribute, needless to say!  And if you have not done so yet, please take a few minutes to participate in the State of Agile survey for this year (and you might win an Apple watch).  Go to www.stateofagile.com

VersionOne consultant, Susan Evans, gave an inspirational experience talk about following your beliefs to ensure your happiness and motivation at work.  Write your own career user story with job satisfaction acceptance criteria.  Are you in the right job?  Do you love your job?   Read her 3 part blog on this topic: http://blogs.versionone.com/agile_management/2015/01/05/99-problems-but-a-coach-aint-one-part-1-of-3/

Steve Ropa, VersionOne consultant, presented “Agile Craftsmanship and Technical Excellence:  How to Get There”.  To change your organization, set an example of “this is what we do here”.  Seek to become a mentor to others and to engage in continuous learning.  Read his blog related to this topic:  http://blogs.versionone.com/agile_management/2015/08/06/how-to-become-a-software-craftsman/

Also, Satish Thatte, another VersionOne Consultant, gave a light-hearted talk on “Scaling Agile Your Way,” based on his blog:  http://blogs.versionone.com/agile_management/2014/10/14/scaling-agile-your-way-how-to-develop-and-implement-your-custom-approach-part-4-of-4/

Then, of course, there were evening festivities.  The best party to be invited to was hosted by VersionOne at Bobby McKey’s Dueling Piano Bar featuring very talented musicians and songs we all knew and loved.  A great time and lots of fun were had by all.  No walking out early here!

The conference party theme on Thursday evening was Super Heroes.  Of course, the real heroes attending that night were those industry leaders who had the vision and the courage to guide their organizations and teams to a winning strategy focused on a culture of agility and lean principles.  One of the sessions presented by Michael Hamman described agile (transformational) leadership as the ability to grow adaptive capability across all aspects of the organization. In another session, Doc Norton encouraged adopting an experimentation-oriented mindset by challenging assumptions, compliance, and fear of failure.  In the closing keynote, James Tamm encouraged us to examine our own personal defensiveness as a way to overcome conflict and unhealthy cultural dynamics so we can move into an open, trusting, and collaborative culture.

Not surprising given the venue, a number of session topics focused on agile in government, dispelling once and for all the myths that agile cannot be successfully applied in the government sector.  The government sectors often face more ingrained cultural challenges to agile adoption than their commercial counterparts including:

  • Federal policies that agencies are audited against and contractor relationships dictated by contractual requirements which address traditional and “waterfallish” approaches
  • Earned value reporting and accounting driven by artifacts and activity versus outcome
  • Contract competitions which stifle collaboration
  • Command and control hierarchy that restrict flow of information and innovation

However this is changing and the fact is that many government agencies are overcoming these barriers and are realizing the benefits of agility.  Coming from the government sector myself and knowing agile works, this success is near to my heart.  And frankly, who should want to see this success more than taxpayers:  a government delivering a continuous stream of value efficiently.

To summarize key takeaways:

  • Scrum is more than a set of process and activities; it is about the continuous delivery of value and getting things done.
  • Large organizations across all industries are scaling agile across the entire enterprise and discussing how to optimize results.
  • To streamline delivery cycle time and improve time to market, you must tackle DevOps and this is the new focus of improvement in many organizations.
  • True agile transformation must address individuals and interactions, establishing a culture of trust and collaboration and alignment to vision and goals. This requires executive level commitment and action.

The closing keynote cited net income improvements of 755% between collaborative and adversarial work environments.  We need to see more leadership willing to tackle these challenges and deliver. It is never too late.

Whether you want to initiate an enterprise level agile transformation or just revitalize your practices, visit ttp://www.versionone.com/customer-success/ for information on getting started with our solution programs.

Finally, mark your calendars for next year’s conference. It will take place from July 25 – July 29, 2016 in Atlanta, Georgia, home base for the VersionOne family.  It promises to be even bigger and better!  Hope to see you there next year for another great learning opportunity and chance to reconnect with old friends and meet and connect with new associates who share your passion for enterprise agility.

Pages

Subscribe to Torak - Agile Scrum Kanban Coaching Training Phoenix AZ aggregator