Skip to content

Feed aggregator

Progress Software Acquired Telerik Teampulse Editor

Scrum Expert - Thu, 10/23/2014 - 19:24
Progress Software Corporation has announced that it has entered into a definitive agreement to acquire privately held Telerik AD for $262.5 million. Telerik enables its 1.4 million strong developer community to create compelling user experiences across cloud, web, mobile and desktop applications. Telerik is the supplier of the TeamPulse Agile project management tool that allows you to use Scrum, Kanban or your own process. Telerik’s revenue for the last twelve months was over $60 million, with annual bookings growth of over 20%. The combination of Progress and Telerik will create a ...
Categories: Communities

Sense, Create, and Respond to Change

Rally Agile Blog - Thu, 10/23/2014 - 14:00

Last week we looked at how today’s global markets require new ways of doing business, so that you can respond quickly to threats and opportunities. We showed you why it’s not enough simply to implement Agile practices into your development shop; you need to build agility into the culture and behavior of your entire organization. And we defined agility as the integral characteristic that allows you sense, create, and adapt to change -- quickly and confidently.

The compelling driver of agility is the speed and impact with which innovations are changing entire industries -- what many refer to as disruption. McKinsey advises that the companies that have survived and thrived amid disruptive change are those that have developed capabilities for speed, transformation, and innovation:

“ … these companies built the organizational capacity and agility required to lead during the disruption. They made big shifts in leadership focus and major changes to resource allocation, and they developed a faster organizational clock speed and leaner cost structure.”

Lest you think disruption is something that hits you like a freight train, one you see coming from a mile away, consider the phenomenon of dematurity: this is what happens when companies in an established industry (say, healthcare, automotive manufacturing, or power) experience a series of small innovations over a short period. Over time these “mini-disruptions” add up, and in the aggregate they can cause radical changes to the industry.

“It is all too easy to be caught off guard—to ignore the small changes that appear one by one, to fail to believe they will affect you, and to end up at the tail of the wave, outpaced by competitors who saw the possibilities earlier,” says PwC strategy and innovation advisor John Sviokla.

“The solution lies in gaining better sensitivity—in other words, improving your ability to recognize and respond to the signals of incremental change."

Get Outside the Building

To sense change, your entire organization needs to be attuned to shifts in the market. You need to leave the office, in a literal and figurative way. You need to gain understanding of the technology driving change and innovation, and you need to regularly take the pulse of the customer.  

As you sense change, your organization must be prepared to both “create” opportunities and “respond” to threats. This is where speed and agility come into play.

Speed is paramount. Information Week’s 2014 Strategic Survey of CIOs cites speed of execution as their top concern. Market windows are incredibly tight, and big companies face competition from nimble start-up competitors.

Agility is what gives companies the ability to move quickly and with confidence. It’s the product of having a disciplined approach to managing change. Agility isn’t a one-time thing; it should become part of your organization’s DNA.

Where to Start

We’ve identified three kinds of agility you need to build across your organization.

Your foundation is execution agility, where speed and performance in your software development help you deliver value faster and gain a competitive advantage.

Then you need to connect your execution with your strategy. Portfolio agility lets you create opportunities with focus and insight into your organization’s highest-value initiatives.

At the broadest level, business agility builds responsiveness into your company culture. You’ll have the confidence to create change through lean innovation and the resilience to respond to change however it impacts you.


Keep learning. Get a copy of the Business Agility Survival Guide.

Rally Software
Categories: Companies

Neo4j: Cypher – Avoiding the Eager

Mark Needham - Thu, 10/23/2014 - 07:56

Although I love how easy Cypher’s LOAD CSV command makes it to get data into Neo4j, it currently breaks the rule of least surprise in the way it eagerly loads in all rows for some queries even those using periodic commit.

Neverwhere

Beware of the eager pipe

This is something that my colleague Michael noted in the second of his blog posts explaining how to use LOAD CSV successfully:

The biggest issue that people ran into, even when following the advice I gave earlier, was that for large imports of more than one million rows, Cypher ran into an out-of-memory situation.

That was not related to commit sizes, so it happened even with PERIODIC COMMIT of small batches.

I recently spent a few days importing data into Neo4j on a Windows machine with 4GB RAM so I was seeing this problem even earlier than Michael suggested.

Michael explains how to work out whether your query is suffering from unexpected eager evaluation:

If you profile that query you see that there is an “Eager” step in the query plan.

That is where the “pull in all data” happens.

You can profile queries by prefixing the word ‘PROFILE’. You’ll need to run your query in the console of /webadmin in your web browser or with the Neo4j shell.

I did this for my queries and was able to identify query patterns which get evaluated eagerly and in some cases we can work around it.

We’ll use the Northwind data set to demonstrate how the Eager pipe can sneak into our queries but keep in mind that this data set is sufficiently small to not cause issues.

This is what a row in the file looks like:

$ head -n 2 data/customerDb.csv
OrderID,CustomerID,EmployeeID,OrderDate,RequiredDate,ShippedDate,ShipVia,Freight,ShipName,ShipAddress,ShipCity,ShipRegion,ShipPostalCode,ShipCountry,CustomerID,CustomerCompanyName,ContactName,ContactTitle,Address,City,Region,PostalCode,Country,Phone,Fax,EmployeeID,LastName,FirstName,Title,TitleOfCourtesy,BirthDate,HireDate,Address,City,Region,PostalCode,Country,HomePhone,Extension,Photo,Notes,ReportsTo,PhotoPath,OrderID,ProductID,UnitPrice,Quantity,Discount,ProductID,ProductName,SupplierID,CategoryID,QuantityPerUnit,UnitPrice,UnitsInStock,UnitsOnOrder,ReorderLevel,Discontinued,SupplierID,SupplierCompanyName,ContactName,ContactTitle,Address,City,Region,PostalCode,Country,Phone,Fax,HomePage,CategoryID,CategoryName,Description,Picture
10248,VINET,5,1996-07-04,1996-08-01,1996-07-16,3,32.38,Vins et alcools Chevalier,59 rue de l'Abbaye,Reims,,51100,France,VINET,Vins et alcools Chevalier,Paul Henriot,Accounting Manager,59 rue de l'Abbaye,Reims,,51100,France,26.47.15.10,26.47.15.11,5,Buchanan,Steven,Sales Manager,Mr.,1955-03-04,1993-10-17,14 Garrett Hill,London,,SW1 8JR,UK,(71) 555-4848,3453,\x,"Steven Buchanan graduated from St. Andrews University, Scotland, with a BSC degree in 1976.  Upon joining the company as a sales representative in 1992, he spent 6 months in an orientation program at the Seattle office and then returned to his permanent post in London.  He was promoted to sales manager in March 1993.  Mr. Buchanan has completed the courses ""Successful Telemarketing"" and ""International Sales Management.""  He is fluent in French.",2,http://accweb/emmployees/buchanan.bmp,10248,11,14,12,0,11,Queso Cabrales,5,4,1 kg pkg.,21,22,30,30,0,5,Cooperativa de Quesos 'Las Cabras',Antonio del Valle Saavedra,Export Administrator,Calle del Rosal 4,Oviedo,Asturias,33007,Spain,(98) 598 76 54,,,4,Dairy Products,Cheeses,\x
MERGE, MERGE, MERGE

The first thing we want to do is create a node for each employee and each order and then create a relationship between them.

We might start with the following query:

USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
MERGE (employee:Employee {employeeId: row.EmployeeID})
MERGE (order:Order {orderId: row.OrderID})
MERGE (employee)-[:SOLD]->(order)

This does the job but if we profile the query like so…

PROFILE LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
WITH row LIMIT 0
MERGE (employee:Employee {employeeId: row.EmployeeID})
MERGE (order:Order {orderId: row.OrderID})
MERGE (employee)-[:SOLD]->(order)

…we’ll notice an ‘Eager’ lurking on the third line:

==> +----------------+------+--------+----------------------------------+-----------------------------------------+
==> |       Operator | Rows | DbHits |                      Identifiers |                                   Other |
==> +----------------+------+--------+----------------------------------+-----------------------------------------+
==> |    EmptyResult |    0 |      0 |                                  |                                         |
==> | UpdateGraph(0) |    0 |      0 |    employee, order,   UNNAMED216 |                            MergePattern |
==> |          Eager |    0 |      0 |                                  |                                         |
==> | UpdateGraph(1) |    0 |      0 | employee, employee, order, order | MergeNode; :Employee; MergeNode; :Order |
==> |          Slice |    0 |      0 |                                  |                            {  AUTOINT0} |
==> |        LoadCSV |    1 |      0 |                              row |                                         |
==> +----------------+------+--------+----------------------------------+-----------------------------------------+

You’ll notice that when we profile each query we’re stripping off the periodic commit section and adding a ‘WITH row LIMIT 0′. This allows us to generate enough of the query plan to identify the ‘Eager’ operator without actually importing any data.

We want to split that query into two so it can be processed in a non eager manner:

USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
WITH row LIMIT 0
MERGE (employee:Employee {employeeId: row.EmployeeID})
MERGE (order:Order {orderId: row.OrderID})
==> +-------------+------+--------+----------------------------------+-----------------------------------------+
==> |    Operator | Rows | DbHits |                      Identifiers |                                   Other |
==> +-------------+------+--------+----------------------------------+-----------------------------------------+
==> | EmptyResult |    0 |      0 |                                  |                                         |
==> | UpdateGraph |    0 |      0 | employee, employee, order, order | MergeNode; :Employee; MergeNode; :Order |
==> |       Slice |    0 |      0 |                                  |                            {  AUTOINT0} |
==> |     LoadCSV |    1 |      0 |                              row |                                         |
==> +-------------+------+--------+----------------------------------+-----------------------------------------+

Now that we’ve created the employees and orders we can join them together:

USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
MATCH (employee:Employee {employeeId: row.EmployeeID})
MATCH (order:Order {orderId: row.OrderID})
MERGE (employee)-[:SOLD]->(order)
==> +----------------+------+--------+-------------------------------+-----------------------------------------------------------+
==> |       Operator | Rows | DbHits |                   Identifiers |                                                     Other |
==> +----------------+------+--------+-------------------------------+-----------------------------------------------------------+
==> |    EmptyResult |    0 |      0 |                               |                                                           |
==> |    UpdateGraph |    0 |      0 | employee, order,   UNNAMED216 |                                              MergePattern |
==> |      Filter(0) |    0 |      0 |                               |          Property(order,orderId) == Property(row,OrderID) |
==> | NodeByLabel(0) |    0 |      0 |                  order, order |                                                    :Order |
==> |      Filter(1) |    0 |      0 |                               | Property(employee,employeeId) == Property(row,EmployeeID) |
==> | NodeByLabel(1) |    0 |      0 |            employee, employee |                                                 :Employee |
==> |          Slice |    0 |      0 |                               |                                              {  AUTOINT0} |
==> |        LoadCSV |    1 |      0 |                           row |                                                           |
==> +----------------+------+--------+-------------------------------+-----------------------------------------------------------+

Not an Eager in sight!

MATCH, MATCH, MATCH, MERGE, MERGE

If we fast forward a few steps we may now have refactored our import script to the point where we create our nodes in one query and the relationships in another query.

Our create query works as expected:

USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
MERGE (employee:Employee {employeeId: row.EmployeeID})
MERGE (order:Order {orderId: row.OrderID})
MERGE (product:Product {productId: row.ProductID})
==> +-------------+------+--------+----------------------------------------------------+--------------------------------------------------------------+
==> |    Operator | Rows | DbHits |                                        Identifiers |                                                        Other |
==> +-------------+------+--------+----------------------------------------------------+--------------------------------------------------------------+
==> | EmptyResult |    0 |      0 |                                                    |                                                              |
==> | UpdateGraph |    0 |      0 | employee, employee, order, order, product, product | MergeNode; :Employee; MergeNode; :Order; MergeNode; :Product |
==> |       Slice |    0 |      0 |                                                    |                                                 {  AUTOINT0} |
==> |     LoadCSV |    1 |      0 |                                                row |                                                              |
==> +-------------+------+--------+----------------------------------------------------+------------------------------------------------------------

We’ve now got employees, products and orders in the graph. Now let’s create relationships between the trio:

USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
MATCH (employee:Employee {employeeId: row.EmployeeID})
MATCH (order:Order {orderId: row.OrderID})
MATCH (product:Product {productId: row.ProductID})
MERGE (employee)-[:SOLD]->(order)
MERGE (order)-[:PRODUCT]->(product)

If we profile that we’ll notice Eager has sneaked in again!

==> +----------------+------+--------+-------------------------------+-----------------------------------------------------------+
==> |       Operator | Rows | DbHits |                   Identifiers |                                                     Other |
==> +----------------+------+--------+-------------------------------+-----------------------------------------------------------+
==> |    EmptyResult |    0 |      0 |                               |                                                           |
==> | UpdateGraph(0) |    0 |      0 |  order, product,   UNNAMED318 |                                              MergePattern |
==> |          Eager |    0 |      0 |                               |                                                           |
==> | UpdateGraph(1) |    0 |      0 | employee, order,   UNNAMED287 |                                              MergePattern |
==> |      Filter(0) |    0 |      0 |                               |    Property(product,productId) == Property(row,ProductID) |
==> | NodeByLabel(0) |    0 |      0 |              product, product |                                                  :Product |
==> |      Filter(1) |    0 |      0 |                               |          Property(order,orderId) == Property(row,OrderID) |
==> | NodeByLabel(1) |    0 |      0 |                  order, order |                                                    :Order |
==> |      Filter(2) |    0 |      0 |                               | Property(employee,employeeId) == Property(row,EmployeeID) |
==> | NodeByLabel(2) |    0 |      0 |            employee, employee |                                                 :Employee |
==> |          Slice |    0 |      0 |                               |                                              {  AUTOINT0} |
==> |        LoadCSV |    1 |      0 |                           row |                                                           |
==> +----------------+------+--------+-------------------------------+-----------------------------------------------------------+

In this case the Eager happens on our second call to MERGE as Michael identified in his post:

The issue is that within a single Cypher statement you have to isolate changes that affect matches further on, e.g. when you CREATE nodes with a label that are suddenly matched by a later MATCH or MERGE operation.

We can work around the problem in this case by having separate queries to create the relationships:

LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
MATCH (employee:Employee {employeeId: row.EmployeeID})
MATCH (order:Order {orderId: row.OrderID})
MERGE (employee)-[:SOLD]->(order)
==> +----------------+------+--------+-------------------------------+-----------------------------------------------------------+
==> |       Operator | Rows | DbHits |                   Identifiers |                                                     Other |
==> +----------------+------+--------+-------------------------------+-----------------------------------------------------------+
==> |    EmptyResult |    0 |      0 |                               |                                                           |
==> |    UpdateGraph |    0 |      0 | employee, order,   UNNAMED236 |                                              MergePattern |
==> |      Filter(0) |    0 |      0 |                               |          Property(order,orderId) == Property(row,OrderID) |
==> | NodeByLabel(0) |    0 |      0 |                  order, order |                                                    :Order |
==> |      Filter(1) |    0 |      0 |                               | Property(employee,employeeId) == Property(row,EmployeeID) |
==> | NodeByLabel(1) |    0 |      0 |            employee, employee |                                                 :Employee |
==> |          Slice |    0 |      0 |                               |                                              {  AUTOINT0} |
==> |        LoadCSV |    1 |      0 |                           row |                                                           |
==> +----------------+------+--------+-------------------------------+-----------------------------------------------------------+
USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
MATCH (order:Order {orderId: row.OrderID})
MATCH (product:Product {productId: row.ProductID})
MERGE (order)-[:PRODUCT]->(product)
==> +----------------+------+--------+------------------------------+--------------------------------------------------------+
==> |       Operator | Rows | DbHits |                  Identifiers |                                                  Other |
==> +----------------+------+--------+------------------------------+--------------------------------------------------------+
==> |    EmptyResult |    0 |      0 |                              |                                                        |
==> |    UpdateGraph |    0 |      0 | order, product,   UNNAMED229 |                                           MergePattern |
==> |      Filter(0) |    0 |      0 |                              | Property(product,productId) == Property(row,ProductID) |
==> | NodeByLabel(0) |    0 |      0 |             product, product |                                               :Product |
==> |      Filter(1) |    0 |      0 |                              |       Property(order,orderId) == Property(row,OrderID) |
==> | NodeByLabel(1) |    0 |      0 |                 order, order |                                                 :Order |
==> |          Slice |    0 |      0 |                              |                                           {  AUTOINT0} |
==> |        LoadCSV |    1 |      0 |                          row |                                                        |
==> +----------------+------+--------+------------------------------+--------------------------------------------------------+
MERGE, SET

I try to make LOAD CSV scripts as idempotent as possible so that if we add more rows or columns of data to our CSV we can rerun the query without having to recreate everything.

This can lead you towards the following pattern where we’re creating suppliers:

USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
MERGE (supplier:Supplier {supplierId: row.SupplierID})
SET supplier.companyName = row.SupplierCompanyName

We want to ensure that there’s only one Supplier with that SupplierID but we might be incrementally adding new properties and decide to just replace everything by using the ‘SET’ command. If we profile that query, the Eager lurks:

==> +----------------+------+--------+--------------------+----------------------+
==> |       Operator | Rows | DbHits |        Identifiers |                Other |
==> +----------------+------+--------+--------------------+----------------------+
==> |    EmptyResult |    0 |      0 |                    |                      |
==> | UpdateGraph(0) |    0 |      0 |                    |          PropertySet |
==> |          Eager |    0 |      0 |                    |                      |
==> | UpdateGraph(1) |    0 |      0 | supplier, supplier | MergeNode; :Supplier |
==> |          Slice |    0 |      0 |                    |         {  AUTOINT0} |
==> |        LoadCSV |    1 |      0 |                row |                      |
==> +----------------+------+--------+--------------------+----------------------+

We can work around this at the cost of a bit of duplication using ‘ON CREATE SET’ and ‘ON MATCH SET':

USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-northwind/data/customerDb.csv" AS row
MERGE (supplier:Supplier {supplierId: row.SupplierID})
ON CREATE SET supplier.companyName = row.SupplierCompanyName
ON MATCH SET supplier.companyName = row.SupplierCompanyName
==> +-------------+------+--------+--------------------+----------------------+
==> |    Operator | Rows | DbHits |        Identifiers |                Other |
==> +-------------+------+--------+--------------------+----------------------+
==> | EmptyResult |    0 |      0 |                    |                      |
==> | UpdateGraph |    0 |      0 | supplier, supplier | MergeNode; :Supplier |
==> |       Slice |    0 |      0 |                    |         {  AUTOINT0} |
==> |     LoadCSV |    1 |      0 |                row |                      |
==> +-------------+------+--------+--------------------+----------------------+

With the data set I’ve been working with I was able to avoid OutOfMemory exceptions in some cases and reduce the amount of time it took to run the query by a factor of 3 in others.

As time goes on I expect all of these scenarios will be addressed but as of Neo4j 2.1.5 these are the patterns that I’ve identified as being overly eager.

If you know of any others do let me know and I can add them to the post or write a second part.

Categories: Blogs

Pliiing, Gong & TickTack: Timeboxen beenden

Scrum 4 You - Thu, 10/23/2014 - 07:45

Dass Timeboxing toll ist, weil es uns ermöglicht, fokussiert und priorisiert zu schnellen Ergebnissen zu kommen und komplexe Umfelder zu stabilisieren, habe ich schon im Blogbeitrag “Was ist so cool an Timeboxing?” geschrieben. Dieses Mal möchte ich meine beiden Lieblingswerkzeuge vorstellen, die mir beim Timeboxing helfen.

Der Timer

Eines der wichtigsten Hilfsmittel, das ich in meiner Arbeit als Design Thinker kennengelernt habe und nicht mehr missen möchte, ist der Timer mit Zeitscheibe zur Visualisierung der Restzeit. Die Restzeit wird dabei durch eine immer kleiner werdende Farbfläche sichtbar gemacht. Das erzeugt positiven Zeitdruck und hilft, Meetings „in time“ zu einem produktiven Abschluss zu bringen. Der Vorteil gegenüber unsichtbaren Timern (z.B. Countdown auf dem Smartphone) ist, dass die Restzeit die ganze Zeit über im Raum sichtbar ist – nicht als abstraktes Zahlenwerk, sondern einfach und plakativ.

Probieren Sie es in einem Daily aus! Der Nutzen für den ScrumMaster ist groß: Es ist die Zeit, die das Meeting nach 15 Minuten beendet, nicht der „böse“ ScrumMaster, der sein Team zur Eile drängt. Es genügt ein Einwurf wie: „Ihr seht, dass wir nur noch 5 Minuten haben?“ und nach Ablauf der Zeit: „Es tut mir leid, aber unsere Zeit ist rum! Ich hatte das Gefühl, ihr zwei wolltet noch etwas sagen? Können die anderen wieder an die Arbeit gehen und wir besprechen das jetzt gleich noch?“ Schauen Sie dazu auch in den Blogbeitrag über Smart Timeboxing.

Unter Begriffen wie TimeTimer und ZeiTimer finden Sie unterschiedliche Varianten am Markt. Es gibt elektronisch gesteuerte Timer: Diese benötigen eine Batterie und haben ein elektronisches Piepsen, das bei manchen Modellen eine Lautstärkenregelung bietet. Kleinere Varianten sind meist rein mechanisch und haben daher durchgängig ein tickendes Geräusch – das kann in längeren, sehr ruhigen Meetings stören. Der Vorteil dieser Varianten ist, dass sie keine Batterie benötigen, sehr gut in das Handgepäck von uns Consultants passen und oft eine magnetische Rückseite haben, mit der sie einfach an jedem Whiteboard halten.

Laszlo Stein

Klangschale und Gong

Mein zweitliebstes Werkzeug nach dem Timer ist der Gong. Bei meinem elektronischen Timer stelle ich gerne die Lautstärke aus und nutze dafür den Gong. Bereits 1-2 Minuten vor Ende der Timebox schlage ich ihn ganz sanft, so dass ein kaum hörbarerer Ton meine Kollegen auf das Ende dieser Phase vorbereitet. Am Ende dann kommt dann ein lauter Schlag.

Es dauert maximal einen halben Tag (5-8 Einsätze des Gongs), bis Menschen auf dieses Signal trainiert sind und Sie damit die Aufmerksamkeit einfach und ohne ein lautes Wort steuern können. Große Gongs und Klangschalen haben eindeutig die schöneren, tieferen Töne. Damit sind auch leise Schläge möglich. Ich persönlich bevorzuge Gongs mit gebogenem Rand, die flachen Gongs (Windgongs) scheppern mir bei den lauten Tönen zu sehr. Aber wie die großen Timer sind sie für des Consultants Handgepäck nicht geeignet. Ich habe deshalb eine sehr kleine Klangschale angeschafft - daher das „pling“! Denn je kleiner die Klangerzeuger, desto höher der Ton. Sanfte leise Töne sind damit nicht möglich, das hohe „pling“ ist sehr durchdringend. Auch Zimbeln können den selben Zweck erfüllen.

Mein Tipp: Gehen Sie in ein Musikgeschäft (oder auch einen Esoterik-Laden, neben Räucherstäbchen und Traumfängern gibt es dort auch oft Klangschalen) und probieren Sie Ihr zukünftiges Hilfsmittel unbedingt aus. Sie werden erstaunt sein, welche Vielfalt sich beim Vergleich der Instrumente auftut und Sie werden irgendwann den Ton hören, den Sie  gerne mitnehmen möchten.

Die Kraft dieser beiden Werkzeuge liegt in der regelmäßigen Benutzung. Sorgen Sie dafür, dass der Einsatz so schnell wie möglich „normal“ wird und Sie werden ein sehr viel leichteres Leben als ScrumMaster haben.

Pliiing…

Related posts:

  1. Timeboxing: Zeitdruck tut gut
  2. Was ist so cool an Timeboxing?
  3. Design Thinking für Product Owner – Teil 3: Der Design-Thinking-Raum

Categories: Blogs

Raising Products

Bobtuse Bobservations - Bob MacNeal - Thu, 10/23/2014 - 07:26
Sunrise to sunset, products have a time-honored cycle. In the realm of software development, I prefer Products over Projects. Product life-cycleWho are the best people to raise a software product?...

Bobtuse can be wildly informative
Categories: Blogs

Assessing Your Enterprise Agility

Danube - Wed, 10/22/2014 - 18:04

I’ve often felt that CollabNet has been at the forefront of paradigm shifts in the software industry.

We founded Subversion, and then spent years driving its development and taking it to market.  Along the way, we added Subversion to our open ALM platform, becoming the leader in combining it with other open source (Git, Gerrit, Jenkins, Nexus, and more) development tools to the enterprise. Ultimately, we were the first to bring cloud-based approaches to large-scale, distributed software development. And, due to the “any tool, any process” nature of our TeamForge ALM platform, we have been hosting Agile initiatives and enabling DevOps long before the terms were coined as new categories.

From a client perspective, the result of this experience helped many of them – and the industry at large – achieve collaboration, business responsiveness, global visibility and innovation at levels never seen before.

Once again, I see another paradigm shift, now from workgroup “agile software development” to organizational-wide “Enterprise Agility.” And, I might add, rightfully so.

Today, many software developers work at multiple sites and use an array of open source, commercial and home-grown tools, along with a range of processes. These disparate tools and processes are often optimized for local workgroups and projects, all at the expense of business agility. This approach slows down software delivery and business responsiveness.

Our view and approach to Enterprise Agility starts with an assessment. Simply put, we’ve packaged the best processes and approaches we developed over the years with our clients as they transformed their global IT into a pragmatic blueprint. Today, we are pleased to announce this formalized process which will predictably and with measurability help organizations become more efficient and responsive. Our new services offering, Enterprise Agility Assessment, is years in the making, and it provides an actionable plan for unifying the flow of software, from planning to production. It helps workgroups achieve individual goals, while at the same time providing repeatability, IP reuse and governance for the company.

The engagement begins by identifying software delivery strengths and weaknesses, specifically those that involve organizational silos. Once the discovery process is complete, we then model a strategic action plan based on our Blueprint for Enterprise Agility.

blueprint enterprise agility Assessing Your Enterprise Agility

Blueprint for Enterprise Agility 

The Blueprint, based on unique organizational dynamics and a realistic pace of change, can be applied to any software organization looking for a practical and measurable business process for embracing Agile development, continuous integration, continuous delivery and continuous improvement. It helps organizations look beyond Agile tools and processes, and to develop the “bigger picture” for enterprise-wide business agility.

Some of the brightest minds in our company, and many customers, have contributed to this Enterprise Agility Assessment.

In the past few months, I’ve travelled globally as we’ve begun rolling this assessment out to our prospects and our partners.  Along the way, I’ve gathered many interesting perspectives on the challenges organizations face when scaling agile and other fractured tools and processes.

I’d like to get your thoughts on Enterprise Agility, too – and the challenges and successes you are seeing as you seek to scale to a global, unified view of Agile and DevOps.

 

The post Assessing Your Enterprise Agility appeared first on blogs.collab.net.

Categories: Companies

Think a Series of Sprints, Not Marathons

J.D. Meier's Blog - Wed, 10/22/2014 - 16:43

When you drive business change and digital initiatives with Cloud, Mobile, Social, and Big Data (and Internet of Things), successful businesses think a series of sprints, not marathons.

Successful businesses go digital by transforming their customer experiences, their employee experiences, and their back-office experiences through rapid prototyping, building proofs-of-concept, testing pilots, and going to production.  It’s a fast cycle of prototype –> pilot –> POC –> production.

These short cycles create rapid learning loops, build momentum, and help adapt for change.

In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of their lessons learned in driving digital initiatives and agile transformation.

The Digital World Moves Quickly

Avoid Big Up Front Design.  Whenever there is a big lag time between designing it, developing it, and using it, you’re introducing more risk.  You’re breaking feedback loops.  You’re falling into the pit of analysis paralysis.   Focus on “just enough design” so that you can test what works and what doesn’t, and respond accordingly.

Via Leading Digital:

“The digital world moves quickly.  The rapid pace of technology innovation today does not lend itself to multiyear planning and waterfall development methods common in the ERP era.  Markets change, new technologies become mainstream, an disruptive entrants begin courting your customers.  Your roadmap will need to be nimble enough to recognize these changes, adapt for them, and course-correct.”

Keep a Vision in Mind and Build on Success Along the Way

Hold on to the vision and use that to guide you as you test your ideas and implement them, without getting bogged down.

Via Leading Digital:

“To design an agile transformation, borrow an approach that has become common among today's leading software companies.  Keep people committed to the end goal, but pace your initiatives as short sprints of effort.  Create prototype solutions, and experiment with new technologies or approaches.  Evaluate the results, and incorporate the results into your evolving roadmap.  Adam Brotman, Starbucks CDO, explained the iterative process: 'We didn't have all the answers, but we started thinking about other things we could do ... I think it worked not to go too far, too fast, but to keep a vision in mind and keep building on success along the way.”

Test Ideas, Save Time, Adapt to Changes

Short cycle times help you respond to market change and adapt as you learn what works and what doesn’t.

Via Leading Digital:

“The test-and-learn approach will require some new ways of working in its own right, but it enjoys some distinct advantages.  By marketing ideas quickly before they go to scale, this approach saves time and money.  It's short cycle times also make it more adaptive to external changes.  Finally, it enables your transformation to sustain momentum through small, incremental successes, rather than the big-bang approach of long-term programs.”

When it comes to your digital strategy and driving business transformation, drive your business change the agile way.

You Might Also Like

10 Ways to Make Agile Design More Effective

Building Better Business Cases for Digital Initiatives

Cloud Changes the Game from Deployment to Adoption

How Digital is Changing Physical Experiences

McKinsey on Unleashing the Value of Big Data Analytics

Categories: Blogs

Cancel Your Executive Status Meetings (Do This Instead)

Rally Agile Blog - Wed, 10/22/2014 - 14:00

Last week I met with a strategy leader for an Australian financial services organization, who was trying to work out how to bring his executive team together on a regular cadence to align around strategy. He’d built a great Kanban board to visualize the large strategic projects the organization was pursuing -- sort of an executive-level roadmap -- and wanted some ideas for how to bring execs together around it.

In my role I spend a lot of time promoting a quarterly, one-day, Agile business steering meeting that brings leaders together to align on strategic priorities and harmonize their quarterly tactics. I think that such a meeting really is the heartbeat of business agility at scale. But once you’re aligned around your intentions for the quarter, how do you steer within the quarter?  

I recommend thinking about three cadences. These include:

  1. A weekly, extended management “impediments” meeting
  2. A weekly executive staff meeting
  3. A bi-monthly metrics meeting
1. Weekly Extended Management Impediments Meeting 

This Scrum of Scrums (SoS) is a short standup meeting involving your extended management team, usually 20-40 people depending on your organization’s size. The purpose of this meeting is to bring junior and senior executives together across departments to raise and resolve impediments encountered on any top priorities.

This is not a status meeting, and indeed, if you have any meeting reporting red / yellow / green status on your tactical initiatives, cancel it right now; you’re wasting time. Initiatives are often green until they’re suddenly red, and by then it’s too late to do anything. Huge amounts of waste goes into producing beautiful status reports that obscure what’s actually going on.

We run the SoS meeting standing in two concentric circles. The inner circle (close to the conference table) is for anyone with important news or significant impediments that they need help with; they’re the ones who speak. The outer circle (against the wall) is for everyone else: they only listen, unless they want to offer help with an impediment. This meeting often lasts just a few minutes, and never more than 30. The group leaves when the inner circle is done and all impediments have been managed.  

an example of an executive meeting format with concentric circles

It can help to track the readouts from this meeting on a simple impediments board, logging recent results, issues, and actions, so that when people walk into the meeting they can quickly recall the context of the last meeting without taking up meeting time.

Just like team-level Scrum, a meeting like this needs a facilitative leader who can keep people focused, handle distractions, and help the group move to action. But at this level, your facilitator needs to be comfortable interrupting senior executives who are rambling. This requires a tricky balance. It can help to ask the group explicitly, “Do I have your permission to facilitate so we can get to results quickly?”

2. Weekly Executive Staff Meeting

It usually makes sense to hold the SoS meeting just before your standing (closed) executive staff meeting, because it gives your senior leadership team the pulse of the issues before doing a deeper dive on their own work. If you’re doing a meeting like this, keep it. If you’re not doing it, start one.

3. Bi-monthly Metrics Meeting

This meeting is a deep dive on key metrics for the business, and may last 1-2 hours. It usually begins with key financial results (revenue, cash flow, and whatever other macro business results make sense for your organization.) Then it dives deeper into your business improvement metrics.

If you’re doing strategy deployment well, you have tactics for improving your business results and leading indicators that tell you whether you’re making progress towards achieving your results. If you’re using a balanced scorecard, all this should be sounding familiar.  

On a regular two- or four-week cadence, your senior leaders should be able to dive deeply into these leading indicators so you can sense whether you need to steer your tactics. If you expected your pipeline to be twice as big in the current quarter, or if you’re seeing a growing backlog in a specific part of your business, you can take action to adapt in the coming business steering meeting. The metrics cadence gives you time to get ahead of this work, so you can steer tactically during your quarterly meeting.

Bringing It All Together

The quarterly meeting is essential to building alignment at this level; once you’re doing it, these three regular meetings enable to you to steer and deliver on your tactical plans.  

What’s the heartbeat of business agility for your organization? 

Learn more about business agility: why you need it, and how to get it. Find out more about how good meetings help you take the pulse of your organization.

  Alex Pukinskis
Categories: Companies

Bye, bye Oldie

tinyPM Team Blog - Wed, 10/22/2014 - 13:54

It already is! The new version of documentation in tinyPM. For those who like to wade through the jungle we left the good old one here. The brand new, more civilized edition, equipped with intuitive menus, which we have prepared using Grails, is available here (www.tinypm.com/docs/guide). We changed the design to a more modern, transparent and consistent color.

Success

Fast but not furious

Previous documentation of tinyPM had a one continuous layout. The new one has a division into sections. It’s easier to navigate as well thanks to the added menu, always displayed on the side. The documentation includes a description of:

tinyPM Docs

From Grails with love

The documentation is generated using the standard mechanism of Grails to create the documentation for the application. Check it out here: grails.org/doc/latest/guide/single.html#docengine. We adapted it to the very great needs of tinyPM to work on our own templates and css styles. The result? A completely different look, and underneath the same syntax wiki for quick and easy creation of documentation.

How do you like it? Are there any gaps, lacks or mistaken attacks? :-)

Categories: Companies

What is UX?

Growing Agile - Wed, 10/22/2014 - 12:09

On Monday Karen and I did a talk with Debre Barrett from Flow Interactive on What is UX? This was at the Scrum Gathering of South Africa. Our aim was to give teams a few techniques that they can use, and tp spread the word that the user should ALWAYS be involved.

The slides are on slideshare: http://www.slideshare.net/growingagile/what-is-ux-40577849

Categories: Companies

Paired Mathematics

Agile Tools - Wed, 10/22/2014 - 07:56

4404087460_9beb6332bd_b

This evening my daughter was sitting at the kitchen table, pencil in hand, confronting a full page of math homework. It was one of those dreadfull rote exercises where one has to solve variations on the same problem over and over again until either the exercises are complete or the child expires from boredom. I remember those math exercises, usually associated with the dictum to “Show your work” – meaning that every exercise would take what seemed like hours to complete. I’m breaking out in a cold sweat just thinking about it.

Nobody I know really likes these sorts of homework assignments. I guess they are a rite of passage in grade school. Seeing the dread in her eyes, I sat down and proceeded to just start talking her through it. It was all the usual stuff. I’d ask questions, and talk about different ways of solving the problem. I’d check her results and ask more questions. And I’d challenge her to do silly things (Write your numbers as tiny as you can. Smaller. smaller!). I’d stop and ask her how she did it, because Dad doesn’t know the new math (I really don’t – today they use all sorts of fun strategies that I never learned as a kid). And of course there was a high five at the end.

And then it occurred to me that we were pair programming!

Well, pair problem solving anyway. She was driving – doing the work. I was navigating, validating her work and thinking about how to tackle the next challenge. We had a dialog going on where we questioned each other. It turns out we both tend to make the same kinds of silly mistakes: like father, like daughter. I just see those mistakes better because I’m navigating, and I’m more experienced.

It seems a very similar pattern to what we do when we are pair programming. Someone is working on the problem, the other is verifying, asking questions, looking ahead. And both are very focused. It’s very intense – requiring full concentration. But, depending on who it is, it can be playful too.

That sounds like a nice way to work. Better than individually grinding away. Of course programming and math problems from grade school are very different things. But it made me wonder, is a place where we all pair a more pleasant place?


Filed under: Agile, practice Tagged: math, pair programming, pairing
Categories: Blogs

Was ist so cool an Timeboxing?

Scrum 4 You - Wed, 10/22/2014 - 07:37

In Scrum und Design-Thinking arbeiten wir eigentlich immer mit Timeboxing. Warum? Was ist so toll an Zeitbegrenzungen?

Wenn Sie einen alten Bekannten an der Bushaltestelle treffen und sagen: “Hey, mein Bus kommt in drei Minuten. Erzähl mir schnell, wie es Dir geht.” Dann können Sie sicher sein, dass er unter den vielen tausend Informationen automatisch die wenigen herauspickt, die er in diesem Moment für die wichtigsten hält. Sicher variieren die Informationen, je nachdem, wie Ihre Beziehung zueinander ist und wie er sich Ihnen gegenüber darstellen möchte. Aber in sekundenschnelle priorisiert Ihr alter Bekannter in der Gewissheit, dass Sie seine Informations-”Lieferung” bewerten werden. Und mit der Sicherheit, dass diese Situation für die nächsten drei Minuten stabil bleibt, dass Sie höflich zuhören und sich auf ihn einlassen werden.

Das machen wir uns auch in unserer täglichen Arbeit zunutze. In meiner Erlebniswelt gibt es drei Aspekte, warum ich Zeitbegrenzungen nicht mehr missen möchte:

  1. Lieferung
    Der wohl offensichtlichste Effekt ist, dass am Ende einer Timebox immer ein bewertbares Ergebnis steht. Am Ende eines Scrum-Sprints wird ein Produktinkrement geliefert. Am Ende einer Research Session steht Information bereit. Am Ende des Meetings stehen Entscheidungen oder ein Informationsaustausch. Und am Ende eines Brainstormings stehen viele Ideen. Die Zeitbegrenzung hilft dabei, die Arbeit zu planen, so dass die Arbeitspakete in die Timebox passen. Eine User Story muss so klein sein, dass sie innerhalb eines Sprints erledigt werden kann. Ein Prototyp muss so gestaltet sein, dass er innerhalb der Präsentations- oder Testzeit bewertet werden kann. Ein Teamtreffen bekommt eine Agenda, die in der bereit gestellten Zeit abgearbeitet werden kann. Das Schöne am Ende der Timebox ist, tatsächlich etwas geschafft zu haben. Und je kleiner die Timeboxen sind, desto häufiger kann man dieses schöne Gefühl genießen. Und sollte es am Ende einer Timebox einmal nicht die erwartete Lieferung geben, so ist auch das ein Ergebnis. Erinnern wir uns an das Sprichwort “lieber ein Ende mit Schrecken als ein Schrecken ohne Ende”. So wird auch aus diesem Ergebnis eine Chance. Die Chance, Dinge, die zu lange brauchen, zu beenden.
  2. Aufmerksamkeit und Fokus
    Mit der Zeitbegrenzung fokussieren wir uns ganz automatisch. Je kürzer die Timebox ist, je stärker der Zeitdruck im Nacken sitzt, desto eher lenken wir unsere Aufmerksamkeit auf die dringendsten Dinge. Stellen Sie sich eine Teenager-Party vor, die Eltern sind das ganze Wochenende verreist … Plötzlich: Es ist Samstag Abend, die Eltern rufen an. Sie kommen noch heute zurück und werden in einer Stunde zuhause sein! Was passiert im Kopf der Tochter / des Sohnes? Ein uraltes Überlebens-Programm springt an: Was dürfen die Eltern auf gar keinen Fall sehen? Und es wird sofort gehandelt! Zeitbegrenzungen lenken unsere Aufmerksamkeit und bringen uns ins Handeln. “Doing as a way of thinking” ist einer unserer Leitsätze bei Boris Gloger Consulting. Der wichtigste Schritt ist der erste! Je weniger Zeit wir haben, desto schneller müssen wir den ersten Schritt gehen.
  3. Stabilität
    Eine Timebox begrenzt in der Regel nicht nur einen Zeitrahmen. Wir legen für die begrenzte Zeit auch andere Rahmenbedingungen fest und schaffen eine stabile Umgebung. Dies ist einer der wichtigsten Aspekte, warum wir mit Scrum wieder Herr des Chaos werden können: In chaotischen und komplexen Umgebungen schaffen wir mit einem Sprint eine Blase der Stabilität. Für 2 Wochen sind die Anforderungen festgeschrieben, auch die benutze Technologie bleibt stabil. Rituale (Meetings) geben einen Rhythmus vor und damit die Sicherheit, dass die Grenzen morgen die gleichen sein werden wie heute. Es ist wie mit Kindern: Auch Kinder benötigen Grenzen, um Sicherheit, um Verlässlichkeit zu spüren, um den Rahmen zu füllen und sich geborgen zu entwickeln. In Scrum ist das der Rahmen, in dem Selbstorganisation wachsen kann. Mitarbeiter und Kollegen “wissen, woran sie sind”. Mit dem nächsten Sprint kann diese Blase der Stabilität natürlich neu positioniert werden, aber der verlässliche Rahmen bleibt immer. Gleiches gilt für kurze Timeboxen. In einer Ideation-Phase im Design-Thinking: Beispielsweise einigen wir uns für 20 Minuten darauf, dass wir die Aspekte der Machbarkeit oder Wirtschaftlichkeit nicht berücksichtigen. In diesem stabilen Rahmen können wir ernsthaft überlegen: “Wie würde Superman das Problem lösen?” oder “Wie funktioniert das auf Raumschiff Enterprise?”
Integration und Konsequenz

Mit großen Timeboxen könne Sie schnell Stabilität erzeugen und mit kurzen Timeboxen erhöhen Sie  schnell die Produktivität. Aber seien Sie vorsichtig: Es geht nicht darum, die Kollegen permanentem Stress auszusetzen. Vielmehr sollen sich Phasen hoher Konzentration und Phasen des Entspannens sinnvoll abwechseln. Achten Sie darauf, dass die Konzentrationsphasen maximal 90 Minuten lang sind und dann von einer Pause unterbrochen werden, die es erlaubt, die Aufmerksamkeit in eine ganz andere Richtung zu lenken.

Und noch ein letzter Hinweis: Zeitbegrenzungen müssen eingehalten werden, damit sie funktionieren! Das klingt einfacher als es ist. Wie Sie sich diese Aufgabe mit einem TimeTimer und einem Gong erleichtern können, lesen Sie in einem anderen Blogbeitrag.

Related posts:

  1. Timeboxing: Zeitdruck tut gut
  2. 15 Minuten sind 15 Minuten
  3. Die Lieferung eines ScrumMasters in sieben Schritten – was er wirklich tut und was nicht

Categories: Blogs

Edge of Tomorrow Today

Portia Tung - Selfish Programming - Tue, 10/21/2014 - 23:10

Love Your Life

Tom Cruise has been a continuous source of inspiration in my personal Agile journey in so many ways.

In Jerry Maguire, he emphasised the importance of “Show me the money!”, a quote I use whenever I talk about prioritisation by business value.

Then there are the diverse and dangerous missions he gets assigned to, to which he always responds with a purposeful smile and a gleam in his eye.

And now his latest film has proved to be the ultimate inspiration to people like us, agents of change for greater good.

The parallels between the hero’s conundrum in Edge of Tomorrow (aka Live Die Repeat) bears more than a canny resemblance to what many of us experience at work. Day after day after day. It’s no wonder then things eventually get us down.

That’s when I remember what Peter Drucker says, grand daddy of organisational culture. “Organisations form and deform people,” he said.

It seemed like such a bleak observation when I first heard it all those years ago, that I found myself boldly reply, “It takes two to tango. People allow themselves to be formed and deformed.”

I know that according to systems thinking a bad system beats good people every time, but what if those good people worked together to improve the system? To change the game for a better tomorrow?

I know how hard things can be when everything seems intent on catching you out or making you stumble.

In my experience, the trick is to keep playing when the going gets tough and make friends. Because you never know when you’ll need them. And a lifelong journey of change is best enjoyed in good company and laughter.

What if each of us could “re-set” and change the future by learning from each moment that passes?

Live. Love. Repeat.

Categories: Blogs

Is Your Culture Working the Way You Think it Is?

Johanna Rothman - Tue, 10/21/2014 - 17:14

Long ago, I was a project manager and senior engineer for a company undergoing a Change Transformation. You know the kind, where the culture changes, along with the process. The senior managers had bought into the changes. The middle managers were muddling through, implementing the changes as best they could.

Us project managers and the technical staff, we were the ones doing the bulk of the changes. The changes weren’t as significant as an agile transformation, but they were big.

One day, the Big Bosses, the CEO and the VP Engineering spoke at an all-hands meeting. “You are empowered,” they said. No, they didn’t say it as a duet. They each said it separately. They had choreographed speeches, with great slide shows, eight by ten color glossies, and pictures. They had a vision. They just knew what the future would hold.

I managed to keep my big mouth shut.

The company was not doing well. We had too many managers for not enough engineers or contracts. If you could count, you could see that.

I was traveling back and forth to a client in the midwest. At one point, the company owed me four weeks of travel expenses. I quietly explained that no, I was not going to book any more airline travel or hotel nights until I was paid in full for my previous travel.

“I’m empowered. I can refuse to get on a plane.”

That did not go over well with anyone except my boss, who was in hysterics. He thought it was quite funny. My boss agreed I should be reimbursed before I racked up more charges.

Somehow, they did manage to reimburse me. I explained that from now on, I was not going to float the company more than a week’s worth of expenses. If they wanted me to travel, I expected to be reimbursed within a week of travel. I got my expenses in the following Monday. They could reimburse me four days later, on Friday.

“But that’s too fast for us,” explained one of the people in Accounting.

“Then I don’t have to travel every other week,” I explained. “You see, I’m empowered. I’ll travel after I get the money for the previous trip. I won’t make a new reservation until I receive all the money I spent for all my previous trips. It’s fine with me. You’ll just have to decide how important this project is. It’s okay.”

The VP came to me and tried to talk me out of it. I didn’t budge. (Imagine that!) I told him that I didn’t need to float the company money. I was empowered.

“Do you like that word?”

“Sure I do.”

“Do you feel empowered?”

“Not at all. I have no power at all, except over my actions. I have plenty of power over what I choose to do. I am exercising that power. I realized that during your dog and pony show.

“You’re not changing our culture. You’re making it more difficult for me to do my job. That’s fine. I’m explaining how I will work.”

The company didn’t get a contract it had expected. It had a layoff. Guess who got laid off? Yes, I did. It was a good thing. I got a better job for more money. And, I didn’t have to travel every other week.

Change can be great for an organization. But telling people the culture is one thing and then living up to that thing can be difficult. That’s why this month’s management myth is Myth 34: You’re Empowered Because I Say You Are.

I picked on empowerment. I could have chosen “open door.” Or “employees are our greatest asset.” (Just read that sentence. Asset???)

How you talk about culture says a lot about what the culture is. Remember, culture is how you treat people, what you reward, and what is okay to talk about.

Go read Myth 34: You’re Empowered Because I Say You Are.

Categories: Blogs

Foundations of Excellence

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

I was thinking about the concept of becoming excellent at something.  My son is a budding artist.  He and I had a conversation a few months ago about talent or aptitude.  I said to him that I felt that aptitude is only latent: you need to put effort into something in order to expose your talent.  He was concerned that he didn’t have any aptitude because he had to work so hard to become better at drawing.  I compared him to myself and my brother, Alexei: when we were growing up, we both put a lot of effort into drawing.  Quickly, I fell behind my brother in skill.  He clearly had aptitude.  But he also put in a lot of effort into exposing that talent.  I was reminded of all this because my son is struggling with math.  He has aptitude, but he hasn’t put much effort into it.  I was wondering why?

Then I realized that aside from aptitude and effort, two more things need to be in place to achieve excellence: willingness and confirmation.

Willingness is the internal drive, usually motivated by an unconscious set of factors, but sometimes also coming from a strong conscious decision.  Willingness can come from unusual combinations of circumstances.  I was extremely willing to learn mathematics in my youth.  This came from two experiences.  One, in grade 2, was when my teacher told me that I shouldn’t be learning multiplication (my dad had taught me while on a road trip).  I was upset that I shouldn’t be able to learn something.  Then, in grade 3, I had a puppet called Kazir (a gift from my babysitter who told stories about space adventures with Azir and Kazir the Baha’i astronauts).  I brought Kazir to school one day and while doing math problems, I pretended that Kazir was helping me.  Suddenly I found math easy.  These two events plus a few others contributed strongly to my desire, my willingness to learn math.

Confirmation is the set of environmental factors that helps keep us on a path of learning.  These environmental factors are sometimes mimicked in the corporate world with bonuses and gamification, but these are really distant shadows of what confirmation is really about. Confirmation is when the stars align, when everything seems to go right at just the right time, when the spirit inspires and moves you and the world to be, in some way, successful.  The trick about confirmation is that success is not usually about monetary success.  It’s usually about social, relational or even sacrificial success.  As an example, when I was in grade 7, I was chosen with a small group of people in my class to do accelerated math studies.  This was a great honour for me and was a confirmation of my interest in math.

In organizational change, and in particular in changing to an Agile enterprise, we need to be aware that excellence requires that these four factors be in place.  Aptitude is, to some degree, innate.  We can’t trick people to have aptitude.  If someone is just fundamentally bad at a certain thing, despite vigorous educational efforts, then that person likely doesn’t have the aptitude.  Effort is about both having time and resources, but also, then about willingness.  And willingness, in turn, can only be sustained with confirmation.  Too much discouragement will break a person’s willingness.  The Agile enterprise requires a great number of skills and abilities that are not normally part of a person’s work environment prior to attempting to adopt Agile.  Keeping these four things in mind can help people in an organization to reach excellence in Agility.

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

TDD and Asychronous Behavior

NetObjectives - Tue, 10/21/2014 - 15:39
Test-Driven Development posits that all behaviors in a system should be specified in tests. Sometimes this appears to be challenging either because the system has design flaws that make it hard to test, or because the technique needed to create the tests is not immediately clear. Sometimes it is a bit of both. At our blog Sustainable TDD, Amir Kolsky and I have outlined the techniques needed for...

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

Do we need a Tech Lead?

thekua.com@work - Tue, 10/21/2014 - 12:03

A common question I hear is, “Is the Tech Lead role necessary?” People argue against the role, claiming a team of well functioning developers can make decisions and prioritise what is important to work on. I completely agree with this position in an ideal world. Sadly the ideal world rarely exists.

Even when perfect conditions exist during which team members talk to each openly, discussing pros and cons before arriving at an agreed solution, it doesn’t take much to upset this delicate balance. Sometimes all it takes is for a new person joining the team, a person leaving or some stressful critical situation that drives the team into a state where arguing continues without end. My friend Roy Osherove calls this the “Chaos state.” I agree with him that a different style of leadership may be required, similar to the Situational Leadership Model.

Technical debates occur frequently in development teams. There is nothing worse than when the team reaches a frozen state of disagreement.

Tabs Spaces
Image take from Emacswiki

The Tech Lead has the responsibility to help the team move forwards. Sometimes that means using their authority. Sometimes it means working with the team to find a way forward. Facilitation and negotiation skills are invaluable assets to a Tech Lead. Understanding decision making models helps the Tech Lead decide when to step in, or when to step back. What is important is finding a way forward.

Tech Leads are also beneficial to people outside of the team, forming a single point of contact. Medium to large organisations start to hit communication barriers because there are too many relationships to effectively build and maintain. The Tech Lead role simplifies the communication path, although simultaneously adds a single point of failure. The balance between these two trade-offs should be carefully managed and monitored.

When played well, the Tech Lead provides countless other benefits, however the Tech Lead role does not have to played by a single person. I admire teams who say they don’t have a Tech Lead and software is still effectively delivered. They have successfully distributed the Tech Lead responsibilities or established processes to mitigate the need for the role. It does not necessarily mean the role itself is useless. The Tech Lead role is just that – just a role. Instead of focusing on whether or not the role should or should not exist, it is better to focus on ensuring all Tech Lead responsibilities are met.

If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Categories: Blogs

Best Practices for a Culture of Continuous Improvement

TV Agile - Tue, 10/21/2014 - 09:14
Doing Kanban for the sake of doing it is unsexy and has usually rather low value. Introducing kanban means working towards the vision of a culture of continuous improvement. Surprisingly, the cultural change does not happen magically after a change agent pushed the practices of Kanban into a company. The cultural change already starts by […]
Categories: Blogs

Fighting Prejudices Against Agile

DevAgile.com - Tue, 10/21/2014 - 08:35
Adopting new software development approaches like Agile and Scrum is always a challenge. There is a natural tendency for part of an organization to resist changing and some prejudices exist against Agile, mainly due to a lack of knowledge.
Categories: Communities

Time After Time

Agile Tools - Tue, 10/21/2014 - 08:07

4e616845-2d64-4eb8-85ab-7f5dcdbab12d

Last year I led an effort to implement time tracking for our teams. A quick warning is probably in order here:

Never, ever, be the person who introduces time tracking at a company. You will be reviled before the gods and your name shall be stricken from the roles of the Agile. People will avoid you at parties, your kids will spurn you, and your pets will pee in your shoes. On the bright side, that Darth Vader helmet you have sitting in the closet will suddenly seem like a good thing to wear around the office.

So, now that we have that out of the way, back to our story. So I was leading this effort to introduce time tracking to all of the developers in our little corner of the company. The idea that had lead to this little misadventure was simple enough: if we used a time tracking tool we will get more detailed information about where time is being spent on projects than if we just make some educated guesses using excel spreadsheets (our existing mechanism). This will give us higher quality information and we will enable us to automatically handle things like capitalization easily.

That was the idea. If we ask people to report their time daily, they will give us a more accurate picture of the time that they are spending on the work. Simple enough. Our old system of excel spreadsheets made a lot of assumptions that probably weren’t true. For example:

  • Everyone works an 8 hour day
  • Everyone on a team works on a given project at the same time
  • Team membership doesn’t change during the sprint

If you use those rules then you can come up with some rough estimates for how many hours the team put into any given project on a sprint by sprint basis. You have to assume that any errors or mistakes will just be averaged out over time. That makes the time tracking very simple to do, but it makes the finance guys twitchy. They get anxious because you are making a lot of assumptions about things that we all know probably aren’t true. And they really don’t like that “It all kinda works out on average” bit either.

So we decided to go down the path of detailed time tracking. Give up all hope ye who enter here. Detailed time tracking doesn’t assume much: every hour of the day must be accounted for. However there is one hidden assumption:

  • Everyone will bother to take the time to accurately report their time for every day.

And there’s the rub. Very few people actually report their time accurately. First, you have to understand that they are ticked off that they are even asked to enter time. Second, they are very likely already entering their time in other places, like agile project management tools, HR vacation tracking tools, contractor management tools, etc. A single person might have to enter their time in 4 different systems! All you have done is add one more tool to the list and it is definitely not welcome.

So how do they use it? They either book all 8 hours of their day to the project and copy and paste every day, or they take one example day and copy and paste that. You aren’t going to get the real data, because the people using the system don’t really want to give it to you. At the end of a long day, nobody wants to have to sit down and try and figure out how much of their day was wasted in all those godawful meetings. They just don’t.

Oh, I suppose you could try policing it better – good luck with that.

You might come away from this little diatribe with the impression that I dislike time tracking. That’s not true. I realize there is a legitimate need for it in our business. However implementing it is much tougher than I realized and it’s very easy to find that the benefits really aren’t that clear at the end of it all.


Filed under: Agile, Process Tagged: benefits, time tracking
Categories: Blogs

Knowledge Sharing


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