Skip to content

Feed aggregator

Healthy Planning with Physicians Mutual

Rally Agile Blog - Fri, 04/11/2014 - 16:40

From life, dental, and accident insurance to Medicare supplements and annuities, the Physicians Mutual family of companies has spent the last 100+ years building nearly $3 billion in assets and consistently earning high ratings for its financial strength.planview-rally-partnership-bridge-diagram.png

The Enterprise Technology Group (ETG) at Physicians Mutual is responsible for strategic and portfolio planning as well as project budgets, managing a portfolio of both Agile-driven and traditional project-driven work. So when it decided to go Agile in 2012, it wanted to choose a solution that would unite strategic and financial planning across multiple business units, and bring visibility and efficiency to its development work.

The PPM/ALM solution provided by the Rally and Planview partnership gives Physicians Mutual an end-to-end portfolio management platform -- from intake, to planning, to execution, to delivery. By connecting “above the line” strategy with “below the line” execution, the Rally and Planview partnership provides capacity and resource planning, strong financial reporting, and a holistic view of work regardless of project methodology.

“What attracted us to both was the partnership -- the two companies really partnered with each other in order to satisfy the customer’s needs,” says Joan Bohannon, Project Manager, PMO Operations, at Physicians Mutual.

Bohannon explains that the company has reached the point where mid-range planning is a key ingredient in helping teams understand what the strategic priorities are, and how those strategies break down into high-level features. “The teams then take those [high-level features] and look to figure out what it’s going to take to develop those features to the business.

“Without mid-range planning, we wouldn’t have any type of pulse on capacity to get those things done, nor any indication that we were working on the right things.”

"Mid-range planning has been very healthy for us.”

The Planview and Rally integration has brought Physicians Mutual a marked increase in transparency and an earlier assessment of risks. Other results:

  • A 50% increase in major product releases year-over-year
  • Substantial cost savings over three years from consolidating solutions and eliminating waste
  • More products to market, faster -- from four major product releases per year to six, along with minor iteration releases
  • Elimination of duplicate entries, meetings, and other process documentation along with efficiencies resulting in over 1,000 man-hours saved per year
  • No more hours spent building reports to support financial analysis, accounting, and statutory reporting
  • Increased visibility into work and resources, leading to better project management and risk mitigation

Hear more about Physicians Mutual Agile Journey at RallyON 2014 in Washington, D.C., June 9 - 11, 2014, or read the case study.

Hannah Shain
Categories: Companies

Prototype Members vs Static Members vs Instance Members (and Dependency Injection)

Derick Bailey - new ThoughtStream - Fri, 04/11/2014 - 13:30

I’m building a job scheduling system where a Schedule contains many ScheduleItems. Each of these ScheduleItems as various dependencies that need to be resolved before the SchduleItem’s “job” is able to run. When a ScheduleItem’s dependencies are all resolved the ScheduleItem will trigger an event and let the parent Schedule know that the Item’s dependencies are resolved. The Schedule can then go about it’s business, saying the job is ready, etc. 

The problem I faced in this setup was needing each ScheduleItem to trigger an event, with a potential for hundreds or thousands of ScheduleItems to be part of a Schedule. I saw a couple of options for this, tried them both, didn’t like either of them. I kept feeling like I was getting 1,000 paper cuts.

Paper set 550809 01 small

But, in the end, found a solution that I do like thanks to Dave Mosher.

Instance Members: Death By 1,000 Paper Cuts

My first solution was to have ScheduleItem inherit from EventEmitter.

In this setup, each ScheduleItem is an instance of an EventEmitter through the magic of util.inherits. That’s cool. It works. I’ve used util.inherits a bunch of times and I like the way it works with EventEmitters, to give me events in my objects. But, this turned out to be bad idea #1. I had to loop through each of the ScheduleItems in my Schedule and have the Schedule attach to the same event on each of them.

That’s potentially 1,000+ event emitter instances with the same number of event handlers being set up. No thanks. 

Dependency Injection: One Paper Cut 1,000 Times

The next trick I tried was injecting a single EventEmitter in to each of my ScheduleItem objects. Sure, I still have to loop through all of my ScheduleItems in order to inject the EventEmitter but that seemed like less of a problem since I would only have 1 EventEmitter.

This turned out to be bad idea #2 because the ScheduleItems are not created by the Schedule itself. They, themselves, are injected in to the Schedule from an external party (they ultimately come from a database). That meant the external party would then be responsible for injecting the EventEmitter in to both the Schedule and the ScheduleItems – far too much knowledge and responsibility leaking out of the Schedule / Item at that point. This totally breaks the encapsulation of the relationship between Schedule and ScheduleItem. 

This is ultimately one paper cut… but it’s one paper cut on 1,000+ objects, being controlled by something that doesn’t feel the pain of those objects. Sounds like torture to me. No thanks.

Static (Type Level) Members: A Paper Cut That Will Never Heal

In C# we call static members “untestable static dependencies” because that’s what they are – a dependency that is “static” to a class somewhere, that cannot be properly tested because it’s static. It starts out looking good, but quickly devolves in to making sure each test resets the static thing properly or working around the left-over static value from the previous tests that ran.

But this is JavaScript, right? It’s dynamic. We can work around those problems and use a “static” member for our event emitter (and by “static”, I mean attributes and methods that are attached to the Type definition). So I did.

Well, it turns out “static” members in JavaScript are just as bad. Yes, it’s true we can just replace the “static” thing in JavaScript whenever we need to. This ends up in the same situation as C#. We’re stuck constantly having to reset or re-initialize the static thing at the beginning of each test because we can’t be sure of what was left-over from the previous test suite. And if you don’t reset it… well, then you end up with things like the EventEmitter “on” limits, which is what I ran in to pretty quickly.

“Static” members, then, are a bad idea in this case (though not in all cases). It’s like a paper cut that will never heals – you think you’ve covered it up and it’s healing, but the next time you look at it, it’s an open wound again, seeping blood. No thanks.

Prototypes: Neosporin For My Paper Cuts

Around this time, I’m annoyed and am looking something better than what I’ve got. So I do my usual thing and blast a question out to twitter, expecting 1,000 people to give me fresh new paper cuts by completely misunderstanding what I’m looking for. By some miracle, though, Dave Mosher manages to understand what I’m asking (in spite of twitter’s limitation on context in 140 characters) and sends me this little gem of a tweet:

@derickbailey few options, constructor dependency injection with the master emitter, or models inherit from object w/ emit function defined.

— Dave Mosher (@dmosher) April 10, 2014

My initial response is something along the lines of saying no I already tried those things. But then somewhere in the back of my mind “inheritance” clicks with “prototypes” and a thought crushed my mind like Obi-Want whispering from the ether: “Luke, use the prototype!”

So I take the best of static members and inheritance, super-collider them together and produce a boson that looks like it’s giving mass to each of my ScheduleItem instances when in reality, it’s just the prototype chain in action!

I now have a way for each ScheduleItem to call this.emit the way I originally wanted, while still allowing a single point of access for all of the ScheduleItem instances, from the Schedule itself. 

Problem Solved!

So remember kids: eat your Wheaties, don’t do drugs, and use prototypal inheritance to your advantage. It’s a good way to get access to a single thing from every instance of your objects, and can prove itself useful in situations where static members, instance members and dependency injection all seem to have more problems than they are worth. 

Granted, there is still potential for paper cuts in the prototypal setup. Each ScheduleItem looks like it is getting it’s own instance of an EventEmitter, but they are actually sharing the same instance. I have to make sure the events that any given ScheduleItem emits includes the ScheduleItem instance as the first parameter. That way the thing listening for the event can get a reference to the actual ScheduleItem that wanted to trigger the event. 

Over-all, though, the potential for paper cuts from this setup seems less than the massive, hemorrhaging paper cuts of the previous ideas. But for now, prototypes are providing a soothing salve to heal the wounds I previously inflicted on my code. 

     Related Stories 
Categories: Blogs

Simplifying cross-platform development - Unity 3.5 Portable Class Library Preview

We are updating Unity DI container to simplify cross-platform development of apps and services. The preview includes the following:

Note, that the Registration by convention feature needed to be pulled out in a separate dll to provide platform-specific implementations.

Please try out the latest changes – the signed builds are available via gallery and the source is available on CodePlex.

Your feedback is invited!

Categories: Blogs

It’s MAD to Use Discovery to Justify the Solution

Constant Change - Aaron Sanders - Fri, 04/11/2014 - 00:57

Have you ever had an executive, a board member, or some other high-ranking person tell you what to build? How were you able to stand up to them? And keep your job? Decreeing the solution happens with such regularity that my Product Owner course is designed to mimic the situation. During the course, I play […]

The post It’s MAD to Use Discovery to Justify the Solution appeared first on Constantly Changing.

Categories: Blogs

How Timelines Help Project Managers Track Progress

TargetProcess - Edge of Chaos Blog - Thu, 04/10/2014 - 21:32

… no matter if it’s agile, Scrum, Kanban, SAFe, lean, XP or some mix of these methodologies.

Project managers want to track progress in any software development project, small or large. Sometimes they want to track progress not only in one, but in many projects at a time, and they want to be able to do this fast and conveniently. A timeline is a a visual management tool that helps accomplish this. Let’s take a closer look in which way.

Regardless of the software development methodology used, projects are meant to be completed. Always. However, at times project managers feel tied to by-the-book canons of Kanban (which is viewed by many as the best visual management system there is, but allows no time-boxing), or of Scrum (which has time-boxed iterations and releases but falls short with the visual part).  What if a project manager wants to get the best both of Kanban, as a visual board, and of Scrum? Obviously, if  projects have deadlines, one can not live by the classical pull and flow formula of Kanban only.

For progress tracking, Scrum allows only one visual report, called the burn down chart. When we want to keep an eye only on one project, such a report would probably be enough:

burn down chart

However, if many projects need a watchful eye of this one person, squeezing many burn down charts on one screen will not make the job any easier. Imagine how hard it would be to make sense of those charts arranged in a grid-like fashion. A project manager will likely want to see how projects correlate with each other, as it might be that the timing in one project affects the other projects. In this case, it would be sensible to drift away from the prescribed tool set of Scrum, and venture into the unknown land, fearlessly mixing sense of time (Scrum) with a neat visual representation (Kanban).  That’s how this stylized mix looks as a timeline view for 2 projects (click to enlarge):

Timelines tracking for many projects

Work items in several projects on a timeline in Targetprocess 3

Such a visualization will fit a dozen projects into one screen, showing a project manager how all of them correlate with each other. This timeline has something more in store, than merely registering projects’ health in terms of time. Unlike in the burn down chart, one will be able to zoom in on any work item in any project and see what’s going on. This timeline bears a certain resemblance to Kanban board, because bugs, user stories and features are presented as cards stretched over time. At the same time, as in Scrum, the forecast will update depending on velocity (if one needs it done that way), and the timeline will show the latest status. If a project manager is in charge of several teams, that do several projects, this timeline will show when one can expect these projects to be completed:


A teams/projects timeline in Targetprocess3

A yet another snapshot of tracking progress with timeline. Here we have Features and User Stories (as in Scrum):Features visualized on a timeline in Targetprocess 3

User Stories inside Features on a timeline in Targetprocess 3

When someone pledges allegiance to Scrum, timelines offer a way to track progress with many iterations. Same for many releases, as opposed to clicking through single release and iteration plans one by one.
Track User Stories by Iteration on timeline in Targetprocess 3

Tracking progress/status for several iterations on a timeline in Targetprocess 3

As we can see, it pays off when we forget about practices that seem to be rigidly prescribed by a methodology. A methodology is nothing, unless it works for our purposes, and helps us do the work better and faster. These timelines can not be, scholastically, classified as belonging solely to Scrum as a method, or to Kanban. While classical Scrum only offers burn down charts for progress tracking, this is not enough when people work with many projects and want to keep their hand on the pulse of all of them. Classical Kanban, in its turn, allows no time tracking as a methodology (and as a visual board). I’m not even sure if what they call “Scrumban” would accommodate this representation with timelines. Frankly, I don’t care how it’s called. I only care if it works for project managers or product owners, or any other folks in charge of projects, and helps them do their work well. And I wish that people were more of a freethinkers, unpinning themselves from the methodology labels.

Care to take a look where one can afford being a freethinker and still work as a project manager? With no strings attached to Kanban, or Scrum, sticking only to common sense and convenience of work? It’s here.

Related articles:

How Visualize: Board, List or Timeline?

Why Visualize?

Categories: Companies

Without Simplicity, There Is no Agility

Scrum Expert - Thu, 04/10/2014 - 16:15
Rich Hickey has stated “The simpler solution is going to kick your butt”, Russ Miles would go further, “The simpler solution is already kicking your butt; no one is more agile than the teams developing with simplicity in mind”. But what makes a complex solution and why is its complexity such a confining force on your ability to be agile and respond to market needs? In this talk Russ Miles, principal consultant at Simplicity Itself, will share the hard lessons learned while designing a real world application that, through applying practical ...
Categories: Communities

Agilia, Budapest, Hungary, June 11-13 2014

Scrum Expert - Thu, 04/10/2014 - 15:59
Agilia is a three-day conference focused on Agile software development. The theme of this edition is the role of product owner and product management in Agile: creating vision, designing product, managing teams, role of Product Owner, engagement of customers and users, creativity and management of innovations. Use cases. In the agenda up you can find topics like “Gamified Retrospective – how to use it to become product/customer-centric team and improve communication with Product Owner?”, “Setting a Good Example: Improving your SBE, BDD and ATDD artefacts”, “The Product Owner’s Work With Specifications”, ...
Categories: Communities

Yet Another $163B Waterfall Disaster

Scrum Log Jeff Sutherland - Thu, 04/10/2014 - 15:32
The F-35 Is Worse Than - Eric Markowitz, 25 Mar 2014The $400 billion jet project is the most expensive weapon the Pentagon has ever purchased. It's also seven years behind schedule and $163 billion over budget ...And here’s the kicker: According to a 41-page Government Accountability Office (GAO) report released yesterday, the F-35, which has yet to fly a single official mission, will stay grounded for at least another 13 months because of “problems completing software testing.”
What GAO Found Delays in developmental flight testing of the F-35’s critical software may hinder delivery of the warfighting capabilities the military services expect. F-35 developmental flight testing comprises two key areas: mission systems and flight sciences. Mission systems testing verifies that the software-intensive systems that provide critical warfighting capabilities function properly and meet requirements, while flight sciences testing verifies the aircraft’s basic flying capabilities. Challenges in development and testing of mission systems software continued through 2013, due largely to delays in software delivery, limited capability in the software when delivered, and the need to fix problems and retest multiple software versions. The Director of Operational Test and Evaluation (DOT&E) predicts delivery of warfighting capabilities could be delayed by as much as 13 months.
Categories: Blogs

Add-Ons Support Custom Reporting & Security Controls

LeanKit Portfolio Edition Add-Ons help you successfully meet your organization’s requirements for additional security controls and highly customized reporting. Now available to our Portfolio Edition customers, Add-Ons offer three ways to further customize your LeanKit experience: Private Cloud offers a virtual, dedicated environment for additional security controls, improved performance and custom backups. Custom Reporting Database includes […]

The post Add-Ons Support Custom Reporting & Security Controls appeared first on Blog | LeanKit.

Categories: Companies

12 Tips for Product Owners who want better performance from their Scrum Teams

Scrum Breakfast - Thu, 04/10/2014 - 12:16
As Product Owner, I want better performance from my Scrum team.

Jeff Sutherland observed that teams in the 95th percentile were 10 times more productive than average teams (50th percentile). He created Scrum to enable all teams to recreate those conditions that enable top performance.

How do you really get better performance from your Scrum team? It’s not about cracking the whip. That is usually counterproductive. It’s about creating the right conditions. In my Product Owner course, we look at the many tools available to Product Owner to enable better and quicker results from the development teams. On the saat-network company site, I have posted 12 tips (well, 13 actually) for how Product Owners can improve Scrum Team performance. Read the whole article...
Categories: Blogs

You do it, you own it.

Growing Agile - Thu, 04/10/2014 - 09:21

Anyone who has been trained by us or coached by us has heard this statement. I’m not sure if we stole it from someone else – the possibility is high (apologies for not crediting!).

YouDoIt 300x280 You do it, you own it.

The next time you find yourself complaining about someone – think of this statement. Are you doing something that you expect that person to then own?  Here is a simple example:

Are you a ScrumMaster who updates the task board to keep it up to date and neat?

Who is the board for? The team. What is the board for? The team to get on the same page and see if they are on track to meet their commitment. So who should be updating the board? The team. You do it, you own it.

I find myself thinking about this statement every time I’m annoyed by someone not doing something I expect. Most times I am the cause of my problem. I am the one that needs to step back to allow that person to step up. And that person is not going to step up automatically. They have probably come to expect you will be doing something. You need to let them know you are not doing it anymore and that it is their responsibility. And then you might need to remind them (not force them).

Recently I was upset with my gardener. He seemed to do nothing without me giving him detailed instructions, and on the days I didn’t he would just leave early. I sat him down and explained that I don’t want to give him detailed instructions, he needs to see my garden as his own and maintain it. I stepped back. And he owned it. Oddly enough, friends of mine who use this same gardener are still complaining that they need to micro-manage him. I told them my story, but they are unwilling to let go. I guess all change takes time.

What are you owning that you shouldn’t be? How can you let go?

Remember: You do it, you own it.



Categories: Companies

Köstlichkeiten und Kostenloses im Alltag eines Unternehmensberaters

Scrum 4 You - Thu, 04/10/2014 - 07:34

Es ist Donnerstag. Böse Zungen sagen auch gerne mal Beraterfreitag. Aber das perlt ab.
Ich habe eingecheckt und befinde mich im Abflugterminal des Flughafens. In dieser speziellen Ausgabe von Flughafen hat sich ein besonders schlauer Fuchs gedacht, es sei geschickt, die kleinen gelben Automaten, an denen man Gefrierbeutel für den sicheren Transport 10x100ml hochexplosiver Flüssigkeiten erwerben kann, 20 Meter hinter der Taschen- und Personenkontrolle aufzustellen. Dann können die Passagiere die Flüssigkeiten, die sie vor dem Sicherheitscheck schon längst entsorgen mussten, endlich in die Plastiktüten packen. Toll!

Mein Tag verlief so lala – der Kunde wusste es mal wieder besser als ich und stellte mich dann gleich noch zusammen mit „dieser ganzen Beraterbande“ grundsätzlich in Frage. Widerstand zwecklos. Definitiv Grund genug, sich mit dem Gedanken an ein kühles Bier anzufreunden. Ich überschlage kurz das verbleibende Reisebudget und stelle fest, dass ich bei Verzehr eines Flughafenbieres wohl noch 4,50 Euro drauflegen müsste, da ich ja bereits heute morgen unbedingt das S-Bahnhof-Ciabatta und den korrespondierenden Kaffee beanspruchen musste. Mittags musste es dann selbstverständlich auch das Mittagsmenü der örtlichen Crossover-Kitchen sein, weil der Kollege, mit dem dieses eine superwichtige Thema besprochen werden wollte, eben dort schon einen Tisch reserviert hatte. Und das im schwäbischen Teil Baden Württembergs – also keine Chance, eingeladen zu werden.

Zurück ins Jetzt. Ich könnte natürlich auf ein kleineres Bier ausweichen…Naääh komm, das würde den Literpreis schlagartig dreistellig werden lassen. Außerdem ist heute Beraterfreitag. Ich entscheide mich für den halben Liter Weißbier vom Fass. Hmmm, wie es so schön in der Abendsonne schimmert, die hinter der Landebahn untergeht. Ich mache noch schnell ein Foto mit meinem inneren Auge und reiße sogleich der Bedienung den Kelch aus der Hand. Dabei verschütte ich etwas von dem kostbaren Gut auf den bereits klebrigen Tresen. Bin wohl nicht der erste halbverdurstete Hobbybierologe heute.

Da vorne am Fenster ist noch ein Plätzchen frei. Ich setze mich und hole meinen Laptop raus. Es ist noch etwas Zeit und ich überlege, einen kleinen Beitrag für unseren Blog zu schreiben. Thema: such dir was aus. Na gut, schreib ich halt was über Leute am Flughafen. Ha! Direkt neben mir hat jemand sein Bier nicht ausgetrunken. Das ist ja noch dreieurofünfzig voll! Also entweder, es war ihm wirklich egal, oder demjenigen ist wieder eingefallen, dass es ein Flughafen mit angeschlossener Kneipe ist und nicht umgekehrt. Oder ihr? Gibt es Frauen, die am Flughafen einen halben Liter Weißbier bestellen und dann die Hälfte zurücklassen? Unwahrscheinlich. Derart leichtsinnig sind doch bestimmt nur Menschen die es gewohnt sind, von einer Sekunde zur maximal übernächsten zu denken (das Bier im 30 Minuten später startenden Flugzeug ist kostenlos!).

Ein paar Meter weiter, eine Tafel: „Jede Pizza nur 10 Euro!!“ Wow, ich bin kurz davor zu Hause Bescheid zu sagen, dass ich im Begriff bin, das Schnäppchen der Woche zu schlagen und zu fragen, ob ich vielleicht noch eine zweite mitbringen soll. Ich schaue mich um, um zu sehen, ob sich dieser Anbieter eventuell in einem erbitterten Preiskampf mit unzähligen weiteren Pizzabäckern befindet. Natürlich nicht. „Do people at the airport know what the prices are at any other place in the world?“, fragte einst der amerikanische Comedian Jerry Seinfeld. Nun ja, ich habe vor ein paar Minuten ein Bier für 6,90 Euro gekauft – bin also Teil des Problems. Der randvollen Auslage nach zu urteilen hat die Pizza heute auch schon einmal 15 Euro gekostet und nun wird voller Enthusiasmus diese Wahnsinnsreduktion beworben. Ausgang ungewiss.

Gegenüber steht das Regal mit dem Zeitschriftenangebot der Airline. Eine Ausgabe des PLAYBOY mit jugendfreiem Einband – zu sehen ist das Bild einer verlassenen Karibikinsel in Häschenkopfform aus der Vogelperspektive – liegt dort aus. Und, was ist das? Ein Mittvierziger mit seinem maximal 10-jährigen Spross geht schnurstracks darauf zu, lenkt den Jüngsten noch kurz mit einer SportBild, auf deren Cover Manuel Neuer gerade irgendwen anbrüllt ab, um dann beherzt ins obere Regal zu greifen. Bold move, daddy! Was wohl Mama dazu sagen würde? Kriegt sie ja nicht mit. Und wenn doch, wird auch er behaupten, es ginge ihm lediglich um die super Reportagen.

Oh, der Flug wird aufgerufen. Für’s Priority Boarding habe ich noch nicht genügend Meilen – Anfänger! Aber ich habe noch etwas Zeit, um den Passagieren bei ihrer besten Engländer-Imitation zuzusehen und die restlichen 2,90 Euro auszutrinken. Nicht dass sich am Ende jemand über mein halb volles (!!) Glas lustig macht. Wie sie sich alle brav anstellen, obwohl sie doch noch laaaange nicht dran sind. Vielleicht sollte ich mal hingehen und darauf aufmerksam machen, dass sich die Sitzplatznummern auch in den verbleibenden 30 Minuten nicht mehr ändern werden. Und „ja, Sie werden mit sehr sehr großer Wahrscheinlichkeit der erste auf dem ausschließlich für Sie reservierten Platz sein“. Mich beschleicht der Verdacht, es könnte sich um traumatisierte Bahnkunden handeln, die auch Angst davor haben, nachts aus ihren Betten geschmissen zu werden, weil sie das „ggf. freigeben“-Schild einfach ignoriert haben. Ich beobachte das Schauspiel noch eine Weile und verpasse um ein Haar noch meine Boarding-Gruppe.

Im Flugzeug komme ich mit meinem Sitznachbarn ins Gespräch. Er erzählt mir davon, wie er aufgrund seiner Leibesfülle schonmal aus den komfortablen Sitzen vor den Notausgängen komplimentiert wurde. „Jaja, Alte, Kinder und Dicke haben keine Chance“, sagt er. Und ich weiß in dieser Situation nicht, wer mir mehr Leid tut: dieser arme Kerl, dem seine stattliche Physis so deutlich vor Augen geführt wurde, oder ich, der auf einmal mit der Hälfte des bezahlten Sitzplatzes auskommen muss. Ich versuche trotzdem, es mir ein bisschen bequem zu machen. Über die Lautsprecher hauchen Simply Red: „I wanna fall from the stars“ in die Kabine. Bei dem Gedanken an den Marketingmitarbeiter mit dem Einfühlvermögen einer Tiefkühltruhe, der tagelang gegrübelt und letztlich beschlossen hat, dass nur genau dieser der richtige Song vor jedem Take-off sein kann, lasse ich mich langsam in den Schlaf rütteln. Das kostenlose Bier werde ich natürlich verpassen.

Related posts:

  1. Die Stiftung Bärenherz bekommt den Bambi
  2. Scrum Lollipops
  3. ScrumMaster Checkliste

Categories: Blogs

At Long Last, SonarQube Is a True Polyglot

Sonar - Wed, 04/09/2014 - 19:52

Good taste prevents me from embedding a trumpet fanfare into this post, but it does seem warranted. After all, with the release of SonarQube version 4.2 last week, SonarSource has finally implemented the all-time highest voted ticket in the SonarQube backlog: multi-language analysis.

Now, at last, you’ll be able to see the Java or C# in your web project side by side with its JavaScript and HTML. Finally, without the Views plugin, you can see aggregate measures across the multiple technologies in a single project for a unified quality assessment. Cue the angel choir.

Okay, now for a tiny dose of reality. The ability to participate in a multi-langauge analysis must be implemented in each language plugin separately, so it may be a while before your project is fully inspected with just one analysis. But very soon you’ll be able to remove the sonar.language property, and SonarQube will automatically analyze every file with an extension it recognizes.

Actually, if even one of the languages in your project already supports multi-language analysis, you can go ahead and drop the sonar.languages property and SonarQube will do its multi-language thing as much as it can. Multi-language analysis has already been released in Android, Flex, Groovy, Java, JavaScript, PHP, PL/SQL, and RPG. It’s scheduled for ABAP, C/C++, C#, COBOL, PL/I, Python, VB6, and VB.NET.

Of course, if you don’t want to turn on multi-language analysis yet, then all you have to do is retain the sonar.languages property, and you’ll get the legacy behavior: analysis only of the single language you specified.

Categories: Open Source

A Primer for Smart Change Agents

TargetProcess - Edge of Chaos Blog - Wed, 04/09/2014 - 19:31

Have you ever tried to act as a change agent in your company, and bumped into obstacles that seemed to be blocking the change? There’s no such software development organization in the world that allows no space for some sort of adjustment. Whether you hit a dead end as a change catalyst, or succeed will mostly depend on the following:

If the change you have in mind is trending — agile adoption can be a good example — then you’re lucky. One will have to apply little effort, because agile has gone mainstream, and there’s lots of information out there as to why and how agile is supposed to be good for a company. In this case, your intrinsic motivation as a change agent syncs with the extrinsic sweeping wave. Not only your organization, but many others will find it easy to jump on the same bandwagon. The change will then happen smoothly as in a domino effect, started by one easy move of a finger. With each new organization adopting agile, the chain extends to embrace more and more companies.

The second scenario for driving change is quite the opposite one. It might be related to a not that obvious trend, but you somehow feel that the way stakeholders treat this thing is in need of a major overhaul. This scenario involves repeating it over and over again that the product that your company develops needs to have a more intuitive user interface. You’d run into inertia as the stakeholders would probably say that all is fine with the user interface, because customers seem to be content with what they have, and revamping “the face” of the software involves some heavy changes in the code, etc. Unless you have some compelling proof that current customers and prospective clients find the user interface confusing, or even walk away, the effort required to boost the change in the attitude by pushing it down the pipe would be akin to that of a weightlifter doing 3 consecutive clean&jerk attempts.

The third scenario for driving change is not as easy, as scenario 1, and not as super-taxing, as scenario 2. It’s more related to an innovative change. Say, you’re still defending a difficult case, such as  improving user experience in enterprise software. There’s no domino effect, and no “join the others” feel in the air. What can one do to trigger this change? How to convince the executives that the time will come when the current clients will not be happy with the bulky UI? The incentive for change in this case should be supported by good old research and analysis methods. Instead of tearing your muscles as with weightlifting (or, rather, breaking your tongue), one has to turn on the head and do a research, taking advantage of  the big data that is, hopefully, available in any company, to make the need for a change appear compelling. If a hollow call to action is rendered into the language of pragmatism, the actual “raw muscle” effort of arguing wouldn’t take more than that of this little girl who uses the power of her opponent to win.

the aikido girl


Related articles:

Back to the Future of Agile Software Development

The Origins of Big Data Trend

Categories: Companies

OpenSSL, HeartBleed And Ubuntu: The Version #’s Don’t Match.

Derick Bailey - new ThoughtStream - Wed, 04/09/2014 - 15:35

I spent a few hours last night patching OpenSSL on my servers for this site, WatchMeCode, etc. It was a pain. The worst part about it, though, was not recompiling things and actually getting the servers patched. The worst part was all the confusion about version numbers. 



If you haven’t heard of it yet, you need to get yourself over to right now. Basically, if you’re using OpenSSL (and who isn’t?) then your servers are vulnerable to attack and having your SSL keys stolen. You need to fix this ASAP by updating your OpenSSL version, recompiling anything that is built against OpenSSL and re-issuing your SSL certificates with keys. 

Yeah, it’s a pain. But it’s necessary.

The Version Problem

The real problem I ran in to last night was version numbers, like I said.

When you look around the internet, you’ll see that everyone says to update OpenSSL to version 1.0.1g – note the “g” – this is the important bit. Everyone says that if you have anything below this letter, then you’re vulnerable. Of course my servers were vulnerable at v1.0.1c. 


I’m running Ubuntu for both and and when I updated my OpenSSL build, I didn’t get v1.0.1g installed. I ended up with v1.0.1e – and a full on panic attack following that. How am I supposed to get v1.0.1g when apt-get only gives me v1.0.1e?!

The Real Version Number

It turns out Ubuntu didn’t update the letter at the end of the version number, when they applied the patch for v1.0.1… or something like that. I’m still not 100% clear on this. But here’s what I do know:

If you are on Ubuntu and you follow all the right steps to update OpenSSL, you will end up with v1.0.1e – and that’s ok.

The thing that you need to check is the LibSSL version, which can be done like this:

The output I get on my servers is:

The important thing to note, here, is the “Version” number at line 8: 1.0.1e-3ubuntu1.2

According to the Ubuntu OpenSSL page, this is the version number that has the HeartBleed patch.

Get this version # on your Ubuntu servers, and you’re good to go.

Check The Patch

As Dan Tao points out in the comments below, this is a frustrating situation trying to figure out if you are safe or not. In the case of Heartbleed, there are tools the check the actual vulnerability and not just the version number checks, hoping you have the right version number. I used to check my servers and got back green reports saying I’m good to go, after doing the updates.

Categories: Blogs

Calculating Velocity FAQ

Agile Coaching - Rachel Davies - Wed, 04/09/2014 - 13:41
Sometimes people get confused about velocity and edge cases of what gets counted or not. It doesn't matter greatly except it helps to do this consistently over time. I wrote a FAQ for our teams because these edge cases come up infrequently and developers often don't remember what rule to apply. I'm sharing a slightly abbreviated version of our Velcoty FAQ as an illustration of working agreements around this. Your team might choose to do this differently and that's okay.
Categories: Blogs

Manage Your Job Search is Out; You Get the Presents

Johanna Rothman - Wed, 04/09/2014 - 13:28

I am happy to announce that Manage Your Job Search is available on all platforms: electronic and print. And, you get the presents!

For one week, I am running a series of special conference calls to promote the book. Take a look at my celebration page.

I also have special pricing on Hiring Geeks That Fit as a bundle at the Pragmatic Bookshelf, leanpub, and on Amazon. Why? Because you might want to know how great managers hire.

Please do join me on the conference calls. They’ll be short, sweet, and a ton of fun.

Categories: Blogs

Agile Planning Fundamentals with TeamStart

Rally Agile Blog - Wed, 04/09/2014 - 13:00

Agile Planning: it’s not an oxymoron.

On Tuesday, April 15, our TeamStart webinar series will answer your questions about Agile Planning. Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give good Q+A. We'll talk about making and keeping commitments, using tracking and metrics to predict delivery, and planning levels with time horizons.

Here are a few questions from past Agile Planning webinars:

  1. How does the product owner role fit into Agile Planning?
  2. Are there guidelines for setting up good planning estimates?
  3. If the team is not able to complete a story before the iteration ends,  or if a critical change is requested, how do we respond?

From an Agile Planning perspective these are related questions. Let’s take a look at the answers to see why.

1. How does the product owner role fit into Agile planning?

Answer:  A product owner initiates and translates the product roadmap into a manageable product backlog. He or she participates in daily standups and manages the product dashboard. The product owner communicates with internal teams and the product manager, to understand the features and requirements and support the release planning and sprint planning exercises. It’s also the product owner’s job to allow the team to manage itself and understand Agile estimation approaches.

Screen Shot 2014-04-08 at 4.48.11 PM.png
5 Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up, Hubert Smits

2. Are there guidelines for setting up good planning estimates?

Answer: The principal guideline when estimating user story size is to employ a comparative approach. For example, rather than estimating in absolute terms, such as hours or days, you use abstract "story points" to compare the sizes of work items with past work the team has completed. Using an example the team is already familiar with helps you establish a baseline. By contrast, task size should be estimated in hours, since a task should be small enough that it doesn’t span more than a working day (about six hours.)

The estimation of stories done in abstract values happens continuously, and well before iteration planning; whereas task estimation is done once during the iteration planning meeting, immediately before the team votes to commit to the proposed work.

3. If the team is not able to complete a story before the iteration ends, or if a critical change is requested, how do we respond?

Answer: When the scope of a user story becomes larger -- either because you underestimated its scope or because a change request comes in -- you should finish the current iteration as planned, and re-plan the remaining iterations in the release. In a situation where the team still has a fixed delivery date, you must work with the business to determine what other committed-to features or functions may be sacrificed to continue to work within the timebox limits. Teams should review burndown charts daily, so that you can spot problems early and mitigate them. When it’s necessary to re-estimate and re-prioritize features, you should signal to the business and stakeholders as soon as possible.

I bet you have at least three questions about Agile! Learn more about Agile Planning. Join Tuesday’s TeamStart webinar.

Rob Ward
Categories: Companies

Schätzt du noch oder baust du schon?

Scrum 4 You - Wed, 04/09/2014 - 07:32

Im einem Projekt verlangte das Management für den kommenden Release, einmal zu schätzen, wie viele Bearbeitertage für die zu liefernde Menge an Funktionalitäten wohl benötigt würden, um einen Forecast abgeben zu können. Die Manager wollten das, weil sie mit der Storypointschätzung per Magic Estimation nicht zufrieden waren. Denn die sagte aus, dass das Scrum-Team bis zur Deadline bei der aktuellen Velocity von 40 Storypoints lange nicht das liefern würde, was eigentlich erwünscht war.

Alte Schule. Statt anzufangen, werden nun viele Arbeitsstunden darauf verwendet, vorherzusagen, wie lange es wohl dauern wird mit der Lieferung. Zeitverschwendung, so meine Hypothese. Zahlen aus 2012 belegen: 74% der IT-Projekte werden in der Zeit überschritten, 59% in den Kosten und 69%, was die Anzahl der gelieferten Features angeht. (Quelle: Standish Group 2013, S.2) Warum also viel Zeit auf die Schätzung verwenden, wenn wir immer wieder sehen, dass sie ohnehin mehr als ungenügend ist?
Ganz einfach: Die Schätzung wird verlangt. Punkt. Eines jedoch sollte die Erkenntnis aus diesen Erfahrungen sein: Lieber mehr Zeit für die Umsetzung verwenden als auf das stunden- oder tagelange Schätzen.

Natürlich gibt es in einem Unternehmen immer Interessengruppen, die Ressourcen und Kosten planen müssen. Aber uns sollte klar sein, dass wir unser „Geschätze“ der Dauer und unsere Methoden stark überdenken müssen. Vor allem auch die Frage, wer denn schätzen sollte. Im konkreten Fall entschied man sich dafür, pro Story und Thema den jeweiligen Experten die Dauer der erwarteten Arbeit schätzen zu lassen. Gefährlich, sage ich, und möchte hiermit auf das Buch „Die Weisheit der vielen“ von James Surowiecki verweisen. Darin behauptet der Autor, dass die Masse stets besser entscheidet als ein Einzelner: „Die Masse ist dumm, dumpf und gefährlich. Dieses verbreitete und von Wissenschaftlern gestützte Urteil ist falsch. Wahlumfragen, Pferdewetten, der Publikumsjoker bei Günther Jauch, Google oder Millionen Steuerzahler belegen: Die Menge entscheidet in der Regel intelligenter und effizienter als der klügste Einzelne in ihren Reihen. Ihre Problemlösungen greifen besser als die von Experten. Vorausgesetzt, jeder Einzelne denkt und handelt unabhängig, die Gruppe ist groß und vielfältig, und sie kann darauf vertrauen, dass ihre Meinung wirklich zählt.“ (aus dem Klappentext)

Prompt versuchte ich nun, Surowieckis Vermutungen in einem kleinen Experiment zu beweisen, um die Schätzweise im Projekt überdenken zu lassen. Ich ließ von jedem im Team schätzen, wie viele orange Bälle in dem Sack waren, den ich mitgebracht hatte. Die Wahrheit lag bei 101 Bällen. Das wusste außer mir jedoch niemand. Die kleinste Schätzung lag bei 50, die höchste (im übrigen von einem Experten für Zahlen) lag bei 150. Im Mittelwert schätzte das Team den Inhalt auf 96 Bälle. Ein beeindruckendes Ergebnis, das erstaunlich nahe an der Realität von 101 lag und die Theorie Surowieckis zumindest unterstützt.

Eine Gruppe von Menschen (je größer desto besser) schätzt immer genauer als der klügste Einzelne.
Genau das ist der Grund dafür, warum der Publikumsjoker bei „Wer wird Millionär“ in den meisten Fällen so zuverlässig funktioniert.
Auch dafür, warum eine Gruppe von Experten mit je nur einem Tipp es 1968 schaffte, den Standort des im im Atlantik havarierten U-Bootes “Skorpion” auf 75 Meter genau zu ermitteln.

Bei all diesen plakativen und hochinteressanten Beispielen erinnern wir uns daran, worum es geht: Mehr Zeit in die Umsetzung als in das aufwändige Schätzen zu stecken.

Bleibt nur noch die Frage: „Schätzt du noch, oder baust du schon?“

Related posts:

  1. …denn wenn Anna größer als Tom ist und Tom größer als Friederike…
  2. Schätztauchen
  3. Die Weisheit der Vielen

Categories: Blogs

Assembla's reaction to the SSL security vulnerability "Heartbleed"

Assembla Blog - Tue, 04/08/2014 - 20:38

heartbleedThe Internet was surprised recently by a bug in the OpenSSL software, called "Heratbleed," that might allow an attacker to see your HTTPS traffic including your password on a Web login form.  You can read about some of the technical details regarding "Heartbleed" here and the OpenSSL 1.0.1g fix here.

We updated the Assembla servers to remove the vulnerability within a few hours of being notified about a fix. Our acceleration provider, Edgecast, had not yet updated their servers with the fix. This extended the time that Assembla users were exposed to the vulnerability for a few more hours. We had turned off Edgecast, causing some pages to render more slowly, until Edgecast's servers were updated. Everything has since returned to normal.

Protect Yourself!
  • It is recommended that you reset your Assembla password. You can do so using the password reset form
  • If you use API keys or tokens, we recommend that you reset your API keys or tokens.
  • If you use the FTP tool, we recommend that you reset your server login credentials and update these credentials in Assembla's FTP tool.

If you have any questions or concerns, please do not hesitate to contact us

Categories: Companies

Knowledge Sharing

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