Continuing with the 100 Things You Must Know to Be Effective In Software Development The purpose of development/IT is to deliver value quickly - not just for a team, but for the entire organization. If you reflect on this, it's not about going fast, it's about removing delays.  Delays are typically waiting for folks, getting feedback late, detecting errors late, or just going to work on...

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

The needs to go faster to market and cut costs, dominating the industry lately, are significantly changing the landscape of software quality. Many pillars of successful quality strategies in the past are just slowing down delivery too much. We will have to find better ways to provide build in quality into our systems, track and [...]

Partnership & Possibilities – Episode 4, Season 3

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 4: THE STAR

“In a team situation, having a star performer becomes a threat and an opportunity. If a person is a star performer, their job is to spread their skills around to other members, to mentor and pair with people so other people’s skills are lifted up to where theirs are.”

Running time 40:50

Have you encountered a star performer in your organization? Was it a positive experience? How did your organization respond to the star performer?

Leave a comment on this blog or email us at leadershippodcast@gmail.com

Summary
Intro – Brief overview of a case study from the Harvard Business Review: the unmanageable star performer. How does an organization leverage a star performer for the benefit of all?
8:40 – Acknowledge the star performer’s achievement and introduce new opportunities to them to become even better.
13:05 – An organization should prepare itself for the potential exit of a star performer. There should be a succession plan in place to mitigate risks.
21:21 – Having a star performer can be a threat and an opportunity.
30:05 – Beyond generating revenue, star performers can possess rare skill sets that are in high demand and which can make the person indispensable.
38:37 – Star performers can enhance their standing in the organization and increase the knowledge base by sharing their skill set with others in the organization.

Resources
Case Study: The Unmanageable Star Performer, Harvard Business Review

Photo Credit: mj*laflaca via Compfight cc

Each Sprint that a Scrum Team does is an opportunity for learning through “inspect and adapt”.  If there is a break or a pause between Sprints, the Scrum Team may forget what it has learned or fail to apply that learning in a timely manner in the next Sprint.  Of course, many Scrum Teams end a Sprint before a weekend and start their next Sprint at the beginning of the next week.  This non-working break is normal and acceptable.  However, a break between Sprints during which some or all Scrum Team Members do other work is not acceptable.

Kennt ihr ihn auch? Den ausgepowerten Product Owner, der vor lauter Terminen seinen Tag doppelt bis dreifach verplant hat? Oder den eifrigen ScrumMaster, der noch abends im leeren Teamraum sitzt und die Retro für den nächsten Tag akribisch vorbereitet? Manche sagen dann: “Das kann nicht gut sein.” Und zitieren das Agile Manifest, das von “nachhaltiger Entwicklung” und von einem “gleichmäßigen Tempo” erzählt, das “auf unbegrenzte Zeit” haltbar sein soll. Häufig geistert dann noch dieses eine Wort herum: Burnout.

Ja, der gute Product Owner hat eine ganze Menge zu tun: Er soll möglichst nah an seinem Team sein, mit dem Kunden im ständigen Kontakt stehen, und darüber hinaus die gestalterische Gewalt über das Produkt haben. Für manchen klassischen Projektleiter bedeutet das ein deutliches Mehr an Aufgaben und an Verantwortung. Auch der ScrumMaster ist, wenn er für sein Team da sein und Scrum in die Organisation tragen soll, gut ausgelastet.

Am Ende eines langen Tages stellt sich dann der Frust über die vielen Stunden ein, die man wieder mit Meetings und Abstimmungen verbracht hat. Spannenderweise beziehen sich die Klagen, die mir zu Ohren kommen, fast immer auf die Quantität. Dabei scheint es eine fest verankerte Vorstellung von “Normalität” zu geben: Der Achtstundentag gilt als das gesunde Maß aller Dinge. Neun Stunden werden noch toleriert, zehn gelten vielerorts schon als grenzwertig – und bei allem, was darüber liegt, erntet man besorgte Blicke und gilt als ernstzunehmender Burnout-Kandidat.

Tomas Chamorro-Premuzic hat im Harvard Business Review einen wunderbar provokanten Text geschrieben, der genau diese Korrelation zwischen Dauer und Last in Frage stellt. Seine Behauptung: Überarbeitung ist nur dann möglich, wenn du keinen Spaß bei der Arbeit hast (http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html):

“Work is just like a relationship: Spending one week on a job you hate is as dreadful as spending a week with a person you don’t like. But when you find the right job, or the right person, no amount of time is enough. Do what you love and you will love what you do, which will also make you love working harder and longer. And if you don’t love what you are doing right now, you should try something else — it is never too late for a career change.”

Nehmen wir das Zitat ernst, sollten wir am Ende eines langen Tages Rückschau halten und für uns prüfen: Was habe ich heute alles gemacht? Was davon hat mir Spaß gemacht, was hat mich herausgefordert, wo ist die Zeit schnell vergangen? Und wo habe ich mich herumgequält, wo war es einfach nur mühsam und frustrierend? Am Ende eines ganztägigen Trainings bin ich manchmal so kaputt, dass ich kaum noch aufräumen und packen kann. Und trotzdem schwebe ich einen halben Zentimeter über dem Boden, halb euphorisiert und halb benommen von den vielen Eindrücken und Erlebnissen des Tages. Die Belastung eines solchen Tages ist enorm, aber sie macht mich nicht fertig. Es ist dann wie ein langer, langer Lauf, an dessen Ende man glücklich auf dem Rasen sitzt und keuchend grinst.

Wenn wir mit Scrum erreichen möchten, dass Menschen anders miteinander arbeiten und daran wachsen, dann können wir nicht einfach weitermachen. Wir müssen uns vielmehr überlegen, was von der bisherigen Arbeitsweise noch Sinn macht, und was komplett gestrichen werden muss.

Drei Vorschläge:

• Meetings auf maximal dreißig Minuten reduzieren und dadurch auf das wirklich Wichtige begrenzen. Eine gut vorbereitete Agenda, ein Moderator (der nur moderiert) und strenge Einhaltung der Timebox.
• In der Mitte des Meetings einen Energizer einbauen (ein kurzes Bewegungsspiel oder etwas mit Humor). So kommt einem die Zeit nur halb so lang vor, eine andere Hirnregion wird aktiviert, man kommt auf andere Gedanken und das Schwere wird etwas leichter.
• Meetings komplett abschaffen. Stattdessen ein Daily zur Synchronisation und dann Open Spaces: Jeder, der ein Anliegen hat, wirbt im Daily dafür, nennt Zeit und Ort. Und jeder, der mit dabei sein möchte, gesellt sich dann einfach dazu. Klingt radikal, ist aber einfach nur eine Umkehrung der Verhältnisse: Wer zuvor über einen “zugemüllten” Terminkalender geklagt hat, der ihm noch den letzten Atemraum genommen hat, darf nun den Luxus eines unbeschriebenen Blatts genießen, das er selber gestalten darf, indem er sich die Themen für den Tag aussucht. Auch das ist mehr Verantwortung, aber es macht den Getriebenen wieder zum Handelnden. Und das kann dazu führen, dass der Job wieder Spaß macht und die Zeit wie im Flug vergeht.

Tomas Chamorro-Premuzic: Embrace Work-Life Imbalance. HBR Blog Network. http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html

Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html

Related posts:

1. Der ScrumMaster als Dienstleister
2. Volles Scrum ist gefragt!
3. Sie können abschalten, wir haben die Vision

30 Days of Getting Results is a hard-core time management course.   

It’s a 30 Day Sprint with a lesson each day, but you can go at your own pace.   For example, I every now and then I scan through it in about 20 minutes to remind myself of the best time management skills to work on.

Some of you have let me know that you can’t get to the site.   I’m not sure why.  

Regardless, I have a free PDF version of 30 Days of Getting Results available.

It’s powerful stuff.   If you want to master time management, productivity, and work-life balance, this short-course will help you do that.

Time management and extreme productivity are a few of the things that I regularly mentor individuals, teams, and leaders on.

It’s 129 pages, and very easy to flip through.

Each lessons includes an exercise to make it real and drive it home.

If you download and go through it, please rate it on Good Reads.

Enjoy.

The concern about continuous improvement has been a constant at Facta TI since the company's inception. This concern made some practices emerge in a natural way, and they quietly became part of our days. In fact, they became so natural to us tha...

Quite a few interesting sessions today:

Google Knowledge Graph

With the Knowledge Graph, Google is trying to give a new dimension to its flagship product: Search.
Users should be able to have a conversation with search, and search should anticipate on a user’s interests by showing related topics.
So search needs to understand the context of searches, in other words: it needs to understand the world. This is where Knowledge Tree comes in handy.
Knowledge Tree is a hugh graph with semantic data about real world entities and their relations. This data has been gathered from Wikipedia, Google+ and many other sources.
The complete tree is viewable and downloadable at freebase.com.

Freebase Api

If you don’t feel like writing your query logic by yourslef, Google also offers a (free) Rest api:
Freebase Api
The following services are offered, many of them have their own JQuery plugin as well:

• autocomplete
• semantic tagging
• entity collections
• geosearch collections
• topical weblinks

Dart: new features

The Dart programming language has been around a few years already. It is Google’s scalable and typesafe alternative for Javascript. It can run in its own VM, in a special version of Chrome, or it can be compiled into Javascript.

During the last year quite a couple of new features have been added. Here are some highlights:

Mixins
Metadata
Lazy loading of libraries
Futures
streams

Also nice: you can try out Dart in realtime on try.dartlang.org

Dart’s performance has been enhanced: native Dart now runs many times faster than Javascript, thanks to, amongst others, utilization of SimD instructions by the Dart VM.

“Chrome DevTools Revolution”

The DevTools in Chrome Canary have been updated with quite a few cool features. It should even be possible now to use Chrome DevTools as your only IDE: inline editing of Javascript and styling was already possible, but now it is also possible to save the edited code to disk (using Ctrl-S).

If you are using an IDE and have edited a source file, Chrome can now detect file system changes and refresh automatically.

Sass support has been added to Chrome DevTools. So you can trace a styling all the way to the Sass reference that defines it, inside Chrome Devtools.
And also here it is possible to automatically reload the page when a sass file has been changed.

A lot of support was added for profiling Javascript:

• Timeline: a view to quickly see which method takes the most cpu cycles
• FlameChart: a view with the same purpose but a different layout
• Canvast profiling: a view showing which paint actions take the most time
• Object allocation tracking: a memory profiler for javascript
• Layout trashing details: a tool that can show inefficiencies or redundant Dom tree building
• and more ..

Portable Native Client

This is Google’s solution to let you run C++ code inside your browser. Actually that was already possible with Native Client, but Portable Native Client makes it easier to create C++ apps that will run on both Arm and x86 architectures.

Obviously Google needed to do a lot to prevent this from being a security risk. So the C++ code needs to be compiled with a custom compiler, which will create a .pexe file; this file runs inside a ‘native client process’ with ‘software fault isolation’. What this means is that Chrome will scan the code before running it, to check for illegal instructions and for illegal access of certain memory regions.
Apart from that, native client code can only be used in applications inside Chrome Webstore.
This all should make Native Clients safe to use.

The advantage of Native Clients is obviously their performance: they run at 80% or 90% of the speed of a fully native application.

But the question is of course: why go through so much trouble, why not just download a fully native application to your cellphone or laptop?
I guess the answer is that such a thing is not possible on Chromebooks. Google is trying hard to make Chrome the universal platform to run all your applications. And with Native Client, you can now get enough performance to run games as well.

In my time playing around with neo4j I’ve run into a problem a few times where I executed a query using the web console (usually accessible @ http://localhost:7474/webadmin/#/console/) and have got absolutely no response.

I noticed a similar thing today when Rickard and I were having a look at why a Lucene index query wasn’t behaving as we expected.

I setup some data in a neo4j database using neography with the following code:

require 'neography'
 
@neo = Neography::Rest.new
 
@neo.create_node_index("Id_Index", "exact", "lucene")
 
node1 = @neo.create_node("Hour" => 1, "name" => "Max")
node2 = @neo.create_node("Hour" => 2, "name" => "Mark")
node3 = @neo.create_node("Hour" => 3, "name" => "Rickard")
 
@neo.add_node_to_index("Id_Index", "Hour", 1, node1)
@neo.add_node_to_index("Id_Index", "Hour", 2, node2) 
@neo.add_node_to_index("Id_Index", "Hour", 3, node3)

I then ran the following query which I was expecting to return all the nodes:

start hour=node:Id_Index("Hour:[00 TO 02] or Hour:[03 TO 05]") RETURN hour

Instead it returned nothing and I couldn’t see anything being logged either.

Rickard pointed out was because the exception is only returned to the API caller and that it would be better to run the query from the Data Browser which is typically accessible from http://localhost:7474/webadmin/#/data/search/

If we run the query from there then we can see what’s going wrong:

BadInputException
 
StackTrace:
org.neo4j.server.rest.repr.RepresentationExceptionHandlingIterable.exceptionOnHasNext(RepresentationExceptionHandlingIterable.java:50)
org.neo4j.helpers.collection.ExceptionHandlingIterable$1.hasNext(ExceptionHandlingIterable.java:60)
org.neo4j.helpers.collection.IteratorWrapper.hasNext(IteratorWrapper.java:42)
org.neo4j.server.rest.repr.ListRepresentation.serialize(ListRepresentation.java:58)
org.neo4j.server.rest.repr.Serializer.serialize(Serializer.java:75)
org.neo4j.server.rest.repr.MappingSerializer.putList(MappingSerializer.java:61)
org.neo4j.server.rest.repr.CypherResultRepresentation.serialize(CypherResultRepresentation.java:57)
org.neo4j.server.rest.repr.MappingRepresentation.serialize(MappingRepresentation.java:42)
org.neo4j.server.rest.repr.OutputFormat.assemble(OutputFormat.java:179)
org.neo4j.server.rest.repr.OutputFormat.formatRepresentation(OutputFormat.java:131)
org.neo4j.server.rest.repr.OutputFormat.response(OutputFormat.java:117)
org.neo4j.server.rest.repr.OutputFormat.ok(OutputFormat.java:55)
org.neo4j.server.rest.web.CypherService.cypher(CypherService.java:94)
java.lang.reflect.Method.invoke(Method.java:597)

There seemed to be some strangeness going on with how Lucene handles the query when a default search field isn’t provided but we noticed that it behaved as expected if we didn’t use an OR since Lucene has an implicit OR between statements anyway.

start hour=node:Id_Index("Hour:[00 TO 02] Hour:[03 TO 05]") RETURN hour

Either way, the lesson for me was if the console isn’t giving a result run the query in the data browser to work out what’s going wrong!

I’ve started work on some new videos and this time it’s all about Agile Estimating, Planning and Contracts. This is the obvious next step having completed Scrum101, and I’m apply some of the lesson that I learnt. I’ve recorded about an hours worth of audio and, at this moment, it feels like I’m about a third of the way through. I think I’ll have about 3 hours worth of material before I’m done.

As an exercise to understand how I want this new material to look and feel, I took the very first topic (Absolute Estimating vs. Relative Estimating) and created a presentation to go along with the audio. This is my first draft, with an unprocessed (for noise reduction or effects) audio. I think it’s a big improvement from what I’ve done before.

I’d love to hear you thoughts and opinions, so feel free to leave a comment below.

Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.

When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!

“We have always had as much time as we have ever had. No more, no less.” – Anon.

In the modern life of daily hustle and bustle, of striving, failing and achieving, we are prone to forget vital things. One of them is this: Time is the most precious asset we have.

Imagine life as a finite timebox. We have as much of it as we have ever had. When the bell tolls, the size of the timebox isn’t open for negotiation.

Instead of thinking yourself time-poor, think of yourself as time-rich. Distinguish between a want and a need. Now how would you choose to invest life time?

And if you haven’t already, see “The Odd Story of Timothy Green“. It’s a story about life, love and living. It’ll really make you think.

To do great things, it helps to study people that do great things and show us better ways to do things.  It helps us build our reference library of what’s possible and it helps inspire us to new levels of success.

Most importantly, it expands our capabilities.

Chalene Johnson is a powerhouse when it comes to personal development.   She continuously pushes herself, while expanding and exploring what’s possible physically, mentally. and emotionally.   She’s a unique blend of entrepreneur, physical fitness expert, choreographer, author, life changer, and motivational speaker … and we can learn a lot from her approach.

I wrote up 27 lessons from Chalene Johson, but my favorite lesson is actually Lesson #7 – Success isn’t magic, it’s a method:

Chalene says, “It’s NOT luck — it’s KNOW HOW. There is a formula for everything.”   You have to study the people that have the results that you want.   Learn from their formula.   Study what made them successful.  If you can find the proven practices and the methods that work, you’ll speed up your success, and you’ll avoid the dead-ends.   Finding a formula helps you establish and practices routines that will help you get better and better over time.

Personally, I’ve found this to be true time and time again.  Whenever I got stuck, it was my strategy or approach.  I just didn’t know the right formula or who to model from.  There’s always a recipe.  One of the most important things I learned on the Microsoft patterns & practices team is that if you look to the right sources, you’ll find the proven practices or the patterns that really work, even if it’s not well-known (in fact, part of our job on the Microsoft patterns & practices team was really to share and scale this knowledge more broadly.)

I’ve shared my personal rapid results formula before in The Way of Success, and it helps elaborate on how to model success in a more effective way.  As Tony Robbins says, success leaves clues.  We just need to be good students of possibility to find them and apply them.

Even if you’re not into working out, I think you'll enjoy lessons from Chalene Johnson on personal development, productivity, motivation, and more.

1. The Scaled Agile Framework®, or SAFe, provides a recipe for adopting Agile at enterprise scale.  It is illustrated in the big picture.

As Scrum is to the Agile team, SAFe is to the Agile enterprise.

2. SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale.  It is field-tested and enterprise-friendly.
3. SAFe is the brainchild of Dean Leffingwell.

As Ken Schwaber and Jeff Sutherland are to Scrum,
Dean Leffingwell is to SAFe.

4. SAFe is based on Lean and Agile principles.
5. There are three levels in SAFe:
   * Team
   * Program
   * Portfolio

At the Team Level:

6. Scrum with XP engineering practices are used.
7. Design/Build/Test (DBT) teams deliver working, fully tested software every two weeks.  There are five to nine members of each team.
8. Rally’s weekly TeamStart webinar series covers the basic practices at the team level.

At the Program Level:

9. SAFe defines an Agile Release Train (ART).  As iteration is to team, train is to program.
10. The ART (or train) is the primary vehicle for value delivery at the program level.  It delivers a value stream for the organization.
11. SAFe is three letter acronym (TLA) heaven – DBT, ART, RTE, PSI, NFR, RMT and I&A!
12. Between 5 and 10 teams work together on a train.  They synchronize their release boundaries and their iteration boundaries.
13. Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI).  A demo and inspect and adapt sessions are held.  Planning begins for the next PSI.
14. PSIs provide a steady cadence for the development cycle.  They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.
15. New program level roles are defined
    * System Team
    * Product Manager
    * System Architect
    * Release Train Engineer (RTE)
    * UX and Shared Resources (e.g., security, DBA)
    * Release Management Team
16. In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles.  If they have deep domain expertise, they are likely to fill the Product Manager role.  If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.
17. SAFe defines a Scaled Agilist (SA) certification program for executives, managers, architects and change agents responsible for leading SAFe implementations.  Rally provides regular public and private Leading SAFe certification classes.
18. SAFe makes a distinction between content (what the system does) and design (how the system does it).  There is separate “authority” for content and design.
19. The Product Manager (Program Manager) has content authority at the program level.  She defines and prioritizes the program backlog.
20. SAFe defines an artifact hierarchy of Epics – Features – User Stories.  The program backlog is a prioritized list of features.  Features can originate at the Program level, or they can derive from Epics defined at the Portfolio level.  Features decompose to User Stories which flow to Team-level backlogs.
21. Features are prioritized based on Don Reinersten’s Weighted Shortest Job First (WSJF) economic decision framework.
22. The System Architect has design authority at the program level.  He collaborates day to day with the teams, ensuring that non-functional requirements (NFRs) are met.  He works with the enterprise architect at the portfolio level to ensure that there is sufficient architectural runway to support upcoming user and business needs.
23. The UX Designer(s) provides UI design, UX guidelines and design elements for the teams.  In a similar manner, shared specialists provide services such as security, performance and database administration across the teams.
24. The Release Train Engineer (RTE) is the Uber-ScrumMaster.
25. The Release Management Team is a cross-functional team - with representation from marketing, dev, quality, ops and deployment – that approves frequent releases of quality solutions to customers.
26. Rally’s monthly Program webinar series provides an overview of Scaling Agile Programs with SAFe.

At the Portfolio Level:

27. PPM has a central role in Strategy, Investment Funding, Program Management and Governance.
28. Investment Themes drive budget allocations.
29. Themes are done as part of the budgeting process with a lifespan of 6-12 months.
30. Portfolio philosophy is centralized strategy with local execution.
31. Epics define large development initiatives that encapsulate the new development necessary to realize the benefits of investment themes.
32. There are business epics (customer-facing) and architectural epics (technology solutions).
33. Business and architectural epics are managed in parallel Kanban systems.
34. Objective metrics support IT governance and continuous improvement.
35. Enterprise architecture is a first class citizen.  The concept of Intentional Architecture provides a set of planned initiatives to enhance solution design, performance, security and usability.
36. SAFe patterns provide a transformation roadmap.

  Legacy Approach Lean-Agile Pattern

#1

Centralized control

Decentralized decision-making

#2

Project overload

Continuous value flow

#3

Detailed project plans

Lightweight business cases

#4

Centralized annual planning

Decentralized, rolling wave planning

#5

Work breakdown structures

Agile estimating and planning

#6

Project-based funding

Agile Release Trains

#7

Projects and PMBOK

Self-managing teams and programs

#8

Waterfall milestones

Objective, fact-based measures and milestones.

Table above reproduced with permission of Leffingwell LLC and Scaled Agile Inc

37. Rally’s monthly Portfolio webinar series provides guidance on Lean | Agile approaches to PPM.

Adoption

38. Adoption focuses on identifying a value stream.  A value stream is a sequence of activities intended to produce a consistent set of deliverables of value to customers.  Value streams are realized via an Agile Release Train (ART).
39. SAFe poses questions to help identify value streams (ARTs):
    * What program might adopt the new process the fastest?
    * Which executives are ready for a transition?
    * What are the geographical locations and how are the team members distributed?
    * What programs are the most challenged, or represent the biggest opportunities?
40. When you identify a value stream, you go “All In” and “All at Once” for that train.
41. Rally is an SAI Gold Partner.  Rally’s cloud-based solutions for managing the Agile development lifecycle directly support SAFe.  Read two independent analyst reports that show why “Rally Software continues its leadership in Agile/Lean.[1]”

[1] The Forrester Wave™: Application Life-Cycle Management, Q4 2012

.content td { padding: 2px 6px; } ol li { margin-bottom: 13px !important; } .safe-table th { background: #444444; font-size: 13px; color: #fff; border: 0; padding: 8px 0 0 8px; } .safe-table td { padding: 11px; background: #f4f4f4; border-top: 3px solid #fff; border-left: 3px solid #fff; } .safe-table td.first_col { border: 3px solid #fff; } .safe-table td { font-size: 13px; color: #444; margin-bottom: 8px } .safe-table td p { margin-bottom: 3px; } Rob Pinna

Navaneeth KN

In this blog post, I will explain another useful example of Twist's customized HTML reports. Usually test scenarios are associated with story cards. Twist simplifies this by allowing scenarios to be tagged to stories.

Thumbnail: 

read more

Countdown: 17 days until RallyON!  As we get closer to the event, we are knee-deep in content (and planning a welcome reception that will knock your socks off). We're refining the sessions and how they map to our overall themes of people, practice, and technology. This year's conference adds a new focus on Rally's platform, and how to optimize up and across the organization.

People - What makes an Agile leader different? What kinds of trade-offs are involved in their decision-making? Find out as Rally's Tim Miller and Christopher Avery explore what it means to consciously lead an Agile organization.  Also find out Jean Tabaka's "secret sauce" that Agile heroes use to keep their world in peace and deliver at scale.

Practice - One of our customers is presenting "Beyond Swarm Soccer," and the name says it all. Are we all chasing the ball, or do we work in concert across the field? Also, as Agile practitioners, how do you know when you're getting better? Applying extensive research, we've identified the Seven Deadly Sins of Agile Measurement, and will discuss which metrics matter.

Technology - We're taking a technical deep-dive this year by sharing lessons learned from both our customers and our own use. Sessions include product development using a build-measure-learn process, creating the most useful and used dashboards, and managing complex QA and test automation.  Our own engineers take center stage to discuss Rally's approach to building Lean product experiments and how we apply that to our product roadmaps.

There are too many great sessions to choose from, so bring a colleague -- or seven -- to share the learning.  We’ll see you next month in Boulder.  

Rally Software

Roy van de Water and Clayton Lengel-Zigich discuss:

• Why teams revisit situations
• Disclosing what you know
• Decider Protocol