Skip to content

Feed aggregator

Neo4j 2.0.0: Query not prepared correctly / Type mismatch: expected Map

Mark Needham - Sun, 04/13/2014 - 19:40

I was playing around with Neo4j’s Cypher last weekend and found myself accidentally running some queries against an earlier version of the Neo4j 2.0 series (2.0.0).

My first query started with a map and I wanted to create a person from an identifier inside the map:

WITH {person: {id: 1}} AS params
MERGE (p:Person {id: params.person.id})
RETURN p

When I ran the query I got this error:

==> SyntaxException: Type mismatch: expected Map but was Boolean, Number, String or Collection<Any> (line 1, column 62)
==> "WITH {person: {id: 1}} AS params MERGE (p:Person {id: params.person.id}) RETURN p"

If we try the same query in 2.0.1 it works as we’d expect:

==> +---------------+
==> | p             |
==> +---------------+
==> | Node[1]{id:} |
==> +---------------+
==> 1 row
==> Nodes created: 1
==> Properties set: 1
==> Labels added: 1
==> 47 ms

My next query was the following which links topics of interest to a person:

WITH {topics: [{name: "Java"}, {name: "Neo4j"}]} AS params
MERGE (p:Person {id: 2})
FOREACH(t IN params.topics | 
  MERGE (topic:Topic {name: t.name})
  MERGE (p)-[:INTERESTED_IN]->(topic)
)
RETURN p

In 2.0.0 that query fails like so:

==> InternalException: Query not prepared correctly!

but if we try it in 2.0.1 we’ll see that it works as well:

==> +---------------+
==> | p             |
==> +---------------+
==> | Node[4]{id:2} |
==> +---------------+
==> 1 row
==> Nodes created: 1
==> Relationships created: 2
==> Properties set: 1
==> Labels added: 1
==> 53 ms

So if you’re seeing either of those errors then get yourself upgraded to 2.0.1 as well!

Categories: Blogs

Quarterly Product Update Webinar

Join us for a roundup of LeanKit’s newest and upcoming features on Thursday, May 1 at 1pm ET.  Jon Terry, LeanKit’s COO, will give a live update and answer questions. During this webinar, you’ll learn how to:  Visualize your date-driven work with the new Calendar View Get the most out of recent UI enhancements Stay connected with […]

The post Quarterly Product Update Webinar appeared first on Blog | LeanKit.

Categories: Companies

Effective Agile at Scale Webinar Series

Net Objectives gets straight to the point when it comes to describing Agile, reminding us that it’s not about iterations, teams, co-location or any of the ways it may be implemented. Instead, Agile is about the fast delivery of business value in a predictable, repeatable manner. With this perspective in mind, join Al Shalloway, CEO of […]

The post Effective Agile at Scale Webinar Series appeared first on Blog | LeanKit.

Categories: Companies

Social Intelligence and 95 Articles to Give You an Unfair Advantage

J.D. Meier's Blog - Sun, 04/13/2014 - 15:56

Social Intelligence is hot.

I added a new category at Sources of Insight to put the power of Social Intelligence at your fingertips:

Social Intelligence

(Note that you can get to Social Intelligence from the menu under “More Topics …”)

I wanted a simple category to capture and consolidate the wealth of insights around interpersonal communication, relationships, conflict, influence, negotiation, and more.   There are 95 articles in this category, and growing, and it includes everything from forging friendships to dealing with people you can’t stand, to building better relationships with your boss.

According to Wikipedia, “Social intelligence is the capacity to effectively negotiate complex social relationships and environments.”

There's a great book on Social Intelligence by Daniel Goleman:

Social Intelligence, The New Science of Human Relationships

According to Goleman, “We are constantly engaged in a ‘neural ballet’ that connects our brain to the brains with those around us.”

Goleman says:

“Our reactions to others, and theirs to us, have a far-reaching biological impact, sending out cascades of hormones that regulate everything from our hearts to our immune systems, making good relationships act like vitamins—and bad relationships like poisons. We can ‘catch’ other people’s emotions the way we catch a cold, and the consequences of isolation or relentless social stress can be life-shortening. Goleman explains the surprising accuracy of first impressions, the basis of charisma and emotional power, the complexity of sexual attraction, and how we detect lies. He describes the ‘dark side’ of social intelligence, from narcissism to Machiavellianism and psychopathy. He also reveals our astonishing capacity for ‘mindsight,’ as well as the tragedy of those, like autistic children, whose mindsight is impaired.”

According to the Leadership Lab for Corporate Social Innovation, by Dr. Claus Otto Scharmer  (MIT OpenCourseware), there is a relational shift:

The Rise of the Network Society

And, of course, Social is taking off as a hot technology in the Enterprise arena.  It’s changing the game, and changing how people innovate, communicate, and collaborate in a comprehensive collaboration sort of way.

Here is a sampling of some of my Social Intelligence articles to get you started:

5 Conversations to Have with Your Boss
6 Styles Under Stress
10 Types of Difficult People
Antiheckler Technique
Ask, Mirror, Paraphrase and Prime
Cooperative Controversy Over Competitive Controversy
Coping with Power-Clutchers, Paranoids and Perfectionists
Dealing with People You Can't Stand
Expectation Management
How To Consistently Build a Winning Team
How To Deal With Criticism
How Do You Choose a Friend?
How To Repair a Broken Work Relationship
Mutual Purpose
Superordinate Goals
The Lens of Human Understanding
The Politically Competent Leader, The Political Analyst, and the Consensus Builder
Work on Me First

If you really want to dive in here, you can brows the full collection at:

Social Intelligence

Enjoy, and may the power of Social Intelligence be with you.

Categories: Blogs

Scrum, XP, SAFe, Kanban: Which Method Is Suitable for My Organization?

Agile World - Venkatesh Krishnamurthy - Sun, 04/13/2014 - 14:12

image I have recently seen the SAFe framework criticized by the Scrum founder as well as the Kanban founder (see "unSAFEe at Any Speed" and "Kanban -- The Anti-SAFe for Almost a Decade Already"). Method wars are not new, however, and could go on forever. In the face of these discussions, it is important to remember the real intent behind Agile methods.

In this recently published Cutter article, I discuss the importance of understanding Agile as a tool rather than as a goal.  I am also proposing some ideas from complexity theory and Cynefin framework to substantiate the need for parallel/safe to fail experiments rather than  handcuffing organizations with single framework/method or a process.

Read the complete article on Cutter

image 

Photo courtesy: Flickr

Categories: Blogs

Question: Advice to a beginning ScrumMaster

Agile & Business - Joseph Little - Sun, 04/13/2014 - 00:31

Virginia asks: “I am a beginning ScrumMaster in a tough situation.  I have some ideas, but I am unsure what to do.  And unsure what to do first.  What can you suggest?”

Answer:  I think this is a common problem.

But, in reality, there is no end of things that a ScrumMaster can do to help the team.

First, take what you already know about Scrum, and remind the Team what Scrum is.  And why….what the values and principles are.

This can be done in a thousand ways.  One example: Post the Agile Manifesto and the Agile Principles in the Team room.  After each Daily Scrum, ask each member of the Team to take two minutes to explain something about one line or one item from the list.

You will be impressed how well they explain the agile ideas to each other.  And then, you can add an additional insight. Maybe something you think they could improve on.

Read or re-read Agile Project Management with Scrum by Schwaber to get lots of stories and ideas about how Scrum should work.

Second, get a better list of impediments.  Ok, let’s be honest — START a list, a public list.  Yes, of course collect the ones they tell you in the Daily Scrum and in the Retrospective.  Add the ones that you see.  Read this blog, and steal some impediments that apply to you and your team.

You want a list of the top 20 things to improve, broken down into actionable things, where you could see, smell, notice improvement in 2 weeks or less.  Yes, you often start with some epic impediments…but just start there…

An impediment is anything, ANYTHING, that is slowing down the Team. Example: Anything that stops a story, slows down the Team. People issues, technical issues, organizational issues, the weather, I need coffee, I need a dentist, we need a different culture, whatever. Whatever.

Ok, we have to discuss two things that happen universally in the Daily Scrum, at least at first.  They don’t divide the tasks into small pieces, and they talk vaguely about what they worked on, and do not focus on what was DONE (completed).  The tasks must be mostly in the 2-4 hour range.  And they must say whether or not it was completed. If a 4 hour task is not completed in one day, clearly there is some kind of ‘impediment’ (eg, I cannot estimate very well).

Then, they must give their biggest impediment. (What slowed them down the most.)  Time itself is not an impediment.

It might be: “I don’t know this area that well.”  Or: “The servers were down.”  Or: “Well, if the tests were automated, then I could have found the bad code faster.”  Or lots of other things.  Saying: “None” is not an option.  Implying that ‘things are so good around here, that there is no way it could possibly get better’ is also not an option.  Things can always be better.

Also, you must give them a challenge.  Tell them: “We have to double the velocity, in a way that we believe, and not by working any harder.  So, what do we have to change to do that?  And imagine that anything could change. Anything. And that the managers will approve anything, if we can make a good case for it.”

For the Retrospective, see also Agile Retrospectives by Derby and Larsen for more ideas to uncover the real impediments. They have forgotten lots of impediments because they have become used to them, or they can’t imagine that it could be changed.

Third, aggressively attack the impediments.  Every day. Every hour.  Take the top one, and go after it. If you can’t fix it yourself, that is fine.  But get someone to.

I do not mean go crazy. Use some common sense. If the cost is greater than the benefit, than do solve it that way.  Sometimes you can only mitigate the impact. Etc, etc.  But still, every day and every hour, attack the top impediment.

Fourth, tell them.  Tell the right people what you will do, what you are doing, and what you have done.

Mostly, you tell the Team.

How?  In the Daily Scrum (you answer the questions, and tell them).  In the Retrospective.  And in other ways that make sense.

Why?  Well, not to brag as such.  But you need to know they care.  They want the ‘fix’ that you will give, are giving, did give them.  Also, once they know things are getting fixed, they will get more creative about talking about things you could fix.

Fifth, keep a list of ‘fixes installed.’  All the things you did, or got done, to make their lives better.

Why? So, when you are discouraged, you can look at the list and get some encouragement.  So, so when the wonder why you are not doing ‘real work’, you can remind them of your value.  So you can justify the managers why you deserve a raise.

Track the list, and make a reasonable guess as to how much of the improved velocity of the team is attributable to the fixed or mitigated impediments. Typically 100% is effectively attributable to you.  Yes, Scrum itself did some (but you still take credit). Yes, the Team did some things, but honestly probably would have done very little without you, or would have done it very much later.  It does not matter that you did not do it ‘with your own hands’.  You made it happen, you were the key.  It does not matter than some improvements cost ‘extra’ money. The benefits were huge, and mostly would never have happened without you.

Do not slack for even one day.

The Team and the customers deserve everything you have to give.  And you too will be rewarded in ways hard to explain but very clear…by all the good things you make happen.

Sixth, to help you become a better ScrumMaster faster, start a ScrumMasters club with other SMs in your area.

Learn from each other. Maybe have a brown bag once a week, and present ideas and experiences to each other once per week over lunch.

That’s a start. There are many places and ways to learn.  As you act, you will discover more ways to learn, and more things to learn about.

Does that help?

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Five links on Software Design

The real lessons in software development come from production. The more frequently you can deploy – more feedback you can generate

@KentBeck

henrik.signature

 

 

 

I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!

Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.


Categories: Blogs

The Industry Life Cycle

J.D. Meier's Blog - Sat, 04/12/2014 - 21:27

I’m a fan of simple models that help you see things you might otherwise miss, or that help explain how things work, or that simply show you a good lens for looking at the world around you.

Here’s a simple Industry Life Cycle model that I found in Professor Jason Davis’ class, Technology Strategy (MIT’s OpenCourseWare.)

image

It’s a simple backdrop and that’s good.  It’s good because there is a lot of complexity in the transitions, and there are may big ideas that all build on top of this simple frame.

Sometimes the most important thing to do with a model is to use it as a map.

What stage is your industry in?

Categories: Blogs

Security Update on CVE-2014-0160 Heartbleed

sprint.ly - scrum software - Sat, 04/12/2014 - 05:30

OpenSSL, the open source cryptographic library reported the Heartbleed vulnerability on April 7, 2014. The vulnerability allows stealing the information protected, under normal conditions, by SSL/TLS encryption.

We have had no evidence that this vulnerability was used against Sprintly but we have taken all necessary precautions to ensure the continued safety of your information. 

Actions We Have Taken 

  1. Within hours of the official report from OpenSSL, we patched and verified all our servers for CVE-2014-0160. 
  2. We use Amazon’s ELB product for load balancing. They patched our region a few hours before we patched our servers. 
  3. We have re-issued new SSL certificates to all our servers. 
  4. We have rotated all of our SSH, Chef, and AWS API keys throughout our infrastructure. 
  5. We have rotated all 3rd party API keys we use to provide services, such as Transloadit (file processing) and Postmark (email).
  6. We have set up our Chef nodes to re-key themselves every 24 hours. We suggest you do the same
  7. Friday night we flushed all active sessions. This means you will have to log into Sprintly again when you get back to work Monday. Apologies in advance for any inconveniences.

Additional Precautions 

You may consider taking these additional precautionary measures on your Sprintly account: 

  1. Change your Sprintly password 
  2. Reset your Sprintly API key 

Both settings may be found in the Profile menu under your Gravatar. 

Again, we have had no indication that this vulnerability was used against Sprintly but do feel that it is a good habit to keep your passwords and security keys regularly updated. 

If you have any questions or concerns, please feel free to contact us at support@sprint.ly.

Categories: Companies

LeanKit Services Not Affected by Heartbleed

You may have heard recent reports of a vulnerability, commonly known as “Heartbleed,” that affects the popular open-source library OpenSSL. We have confirmed that the LeanKit application and our internal supporting services are not affected by this vulnerability. This bug, officially referenced as CVE-2014-0160, is not an issue with the design of SSL but is […]

The post LeanKit Services Not Affected by Heartbleed appeared first on Blog | LeanKit.

Categories: Companies

Feature Cards

Agile Game Development - Fri, 04/11/2014 - 17:33
My previous article described Feature Boards, a variation of task boards that some agile game teams find more useful.  The main difference between a by-the-book task board and a Feature Board is that task boards contain task cards, which are markers for individual tasks the team foresees will be needed to complete a set of features,  while a Feature Board contains Feature Cards, which are markers for the features themselves.  This article describes a typical Feature Card.


An example Feature Card
The above card shows some typical elements:

  • Card Color: Using a simple color priority scheme (e.g. red, yellow, green) can help teams decide the order of features to work on based on their priority in the backlog or any dependencies that exist between them.
  • Title:  In this case “Jump”.
  • Description: Very often written in a User Story format.  This briefly describes the feature from the point of view of the user, such as the player .
  • Acceptance criteria: While planning an iteration, teams will capture some unique aspects of the feature that will need to be tested.  For example, it might be important to the product owner that the blending of animations be smooth and without popping.  Someone, usually a tester, will write this criteria the back of the card to remind the team to test the feature to ensure there is no popping while jumping.
  • Start and End Dates: It’s useful to capture the day when the team starts working on a feature and when it’s done.  As mentioned in the article about Feature Boards, it’s not best to work on too many features in parallel during an iteration.  Using the dates will allow a team to measure how much work in progress is occurring during the iteration.  I’ll describe how this is used in an upcoming article on Feature Board Burndown Charts.
  • Estimates: As a part of iteration planning, each discipline will discuss the plan for implementing their portion of the feature and may want to capture some time estimates.  Some teams use hours, some days, while some teams will skip estimates altogether.  Capturing discipline estimates rather than individual estimates increases collaboration among members of the same discipline.  These estimates are used to track whether an individual discipline is at capacity or not while features are planned.  For example, if a team is finding that the sum of all animation work across all features adds up to more time than their one full-time animator can handle, they’ll find another animator to help them or they’ll change which features they commit to.
  • Tasks: Tasks captured during planning or during the iteration can be annotated on the card with smaller post-its or, by using larger cards, be written on the cards themselves.  If you use post-its, make sure you use the brand name ones with the good glue!
  • Card Size: Feature cards are usually written on a 3x5 or 4x6 index card.  

VariationsThe sky is the limit on how to format these cards.  For example, some teams record the story points or t-shirt sizes on the cards and don’t use time estimates.  Some teams will break down larger features into sub-features and track the completion of those.  The key is to collect meaningful metrics that are part of an ecosystem to help the team better plan, execute and deliver features at ideal quality.
NextWe’ll look at an optional burndown or throughput tracking chart.


Categories: Blogs

Is Your Sprint Pipeline Running Well?

Agile Management Blog - VersionOne - Fri, 04/11/2014 - 16:55

Most agile teams, when starting out new on their agile transformation road, conduct all sprint related activities in the same timebox, i.e., sprint planning, sprint execution, sprint review and sprint retrospective.  This is illustrated in Figure 1, where each sprint (from Sprint 0 through N+1, represented by each row) is mapped onto a single sprint timebox (Timebox 0 through N+1, represented by each column), and successive sprints are executed in successive timeboxes in a sequential order (Sprint 0 in Timebox 0, Sprint 1 in Timebox 1, and so on).

Figure1

 Figure 1: Sequential execution of sprints

For example, all implementation tasks for Sprint 2 (analysis, design, code development and unit testing, acceptance test case development and acceptance testing, defect fixing – done concurrently (not as a mini-waterfall) by a self-organized, cross-functional team — are completed in Timebox 2.  Sprint 2 planning is completed (before Sprint 2 starts) in approximately 4 hours for a two-week sprint (or 8 hours for a four-week sprint); and sprint review and retrospectives are completed in approximately 1 hour each for a two-week sprint (or about 2 hours each for a four-week sprint).

Each light pink vertical thin box separator between two successive sprint timeboxes represents a small timebox to complete all these ceremonies, i.e., sprint review and retrospective for the previous sprint as well as sprint planning for the next sprint.   Thus all these tasks for successive sprints are carried out in a sequence of successive timeboxes.  This is a simple and straightforward model where work goes in each timebox sequentially, sprint by sprint, without any overlap.

What are the advantages of and the challenges for the simple model of sequential sprint execution shown in Figure 1?

Advantages of the sequential sprint execution model:

1AS.    Simple to teach, understand and learn – and hence covered by all agile text books, training courses, and certification programs.

2AS.    Conceptually simple to execute — but fraught with challenges as explained below.

Challenges for the sequential sprint execution model:

1CS.     Analysis issues may block the team and reduce throughput: Analysis of backlog items (or stories, as they are often called) must involve intense conversations among the product owner and team members, and confirmation of each story by defining its acceptance criteria.  Stories can be properly understood only through conversation and confirmation parts of the story metaphor of card, conversations, and confirmation.   The product owner should answer the questions and clarify the issues raised by the team members before design and code development work can start.     This goal – clarifying all stories to reach a collective, common, shared understanding – may become very challenging if all stories are analyzed during the same timebox in which they are scheduled for design, code development, testing, defect fixing and delivery.   This is so because the product owner may not know all the answers to team members’ questions without consulting users, customers and stakeholders, and performing necessary market and customer research and analysis.  This entire analysis effort is often difficult to compress in the same timebox when design-development-testing-defect fixing work is also going on concurrently because the actions of many actors responsible for providing answers to the analysis questions may be beyond the control of the product owner (for example, some stakeholders or customers may not be available to provide specific clarifications within the timebox time constraints).   The net effect of this challenge is often reduced team velocity (throughput) as the team is still waiting for stories to be clarified while sprint execution is going on, and team members may be even blocked waiting for clarification.  Finally the sprint timebox may be over before some planned stories could be completed by the team members and accepted by the product owner.

2CS.     Sprint planning may be less effective and efficient: Without clear and shared understanding of each story by all team members and the product owner, the team will find it difficult to estimate the work effort and complete all sprint planning tasks in the allocated time for sprint planning (approx. 4 hours for two-week sprints and 8 hours for four-week sprints).   Needless to say poorly planned sprints contribute to poor (ineffective and inefficient) sprint execution and reduced throughput.

A better model to overcome the challenges of the sequential sprint model is to execute sprints in a pipeline fashion as illustrated in Figure 2, where the Analysis task is performed one timebox ahead of the Design-Code-Test timebox for each sprint.  For example, development and analysis of Sprint 2 backlog is performed during Timebox 1 (one timebox ahead of Timebox 2), while the actual design, code development and unit testing, acceptance test cases development and testing, regression testing and defect fixing tasks for Sprint 2 are performed in Timebox 2.  This same pattern repeats for each sprint, i.e., the work for each sprint proceeds in a pipeline manner, and as a consequence, the work for each sprint is spread over two consecutive timeboxes in an overlapping manner with the next sprint.

Figure2

Figure 2: Sprint pipeline

 What are the advantages of and challenges for the pipeline model of sprint execution shown in Figure 2?

Advantages of the pipelined sprint execution model: 

1AP.   Analysis work proceeds smoothly without blocking the team: As analysis work is carried out one timebox ahead of design-development-testing-defect fixing work for each sprint, the stories are substantially clearer by the time the team enters the Sprint Planning Workshop for each sprint.  Note that the product owner has a full sprint timebox (typically 2 to 4 weeks) to consult with the necessary users, customers and stakeholders in order to answer team members’ questions on stories.  And while this clarification of stories for the next sprint is going on, the team members are not held up or blocked as they are implementing the stories for the current sprint.   Effort estimation and other sprint planning work proceeds more smoothly and can be more easily completed during the Sprint Planning Workshop.

2AP.   Team experiences higher throughput with well understood stories and well-planned sprint: Note that although each sprint work is spread over two timeboxes (as shown by the blue oval in Figure 2), the throughput is not adversely impacted because the team is still delivering working software at the end of each timebox.   In fact, as sprint planning effectiveness and efficiency goes up and stories become clearer, there is a lot less uncertainty about stories as the sprint starts, which reduces impediments, improves team morale and dynamics, and improves team’s throughput compared to sequential execution of sprints.

Challenges for the pipelined sprint execution model: 

1CP.   In each timebox, the team needs to work on two sprints: Although most of the time the team is focused on design-code development-testing-defect fixing work for the current sprint, some of its time must be set aside to analyze the backlog items prepared by the product owner for the next sprint.  This is indicated by the red oval in Figure 2, where the team is spending most of its effort on design-code development-testing-defect fixing for Sprint 2 in Timebox 2, while at the same time spending some effort in analyzing the stories for Sprint 3.   Some teams — especially when they are new to agile — may find working on two sprints in the same timebox challenging.

2CP.   Small risk of doing wasteful work: There may be a small risk of analyzing few stories one timebox ahead of their actual implementation that may end up not being part of the next sprint commitment due to change in priorities as the next sprint planning is completed.   Some people may even object that doing analysis one timebox ahead of the actual implementation could be somewhat wasteful, and it goes against the “just-in-time” agile work philosophy.

I will now explain how to deal with both of these challenges, 1CP and 2CP.

Solution to the challenge of working on two sprints in the same timebox (1CP): The ScrumMaster for the team can help manage work on both sprints in the same timebox (i.e., design-development-testing-defect fixing work for the current sprint as well as analysis of backlog items for the next sprint) by establishing and following a Sprint Cadence Calendar as illustrated in Figure 3.

Figure3

 Figure 3: Two-Week Sprint Cadence Calendar

The two-week Sprint Cadence Calendar has 10 work days, with workday starting at 8:00 AM (0800 hours) and ending at 5:00 PM (1700 hours). The team should allocate about 30 minutes for preparation for the Daily Scrum (DS) meeting and actual attendance by each team member.  These DS meetings should be held every day of the sprint at the same time and place.   In Figure 3, these DS meetings (preparation and actual meeting) are shown as starting at 9:00 AM and ending around 9:30 AM every day.  If you are interested in understanding and implementing highly effective and efficient Daily Scrums, please take a look at my Making-daily-scrum-meetings-really-effective-efficient blog on the subject.  The other ceremonies (Sprint Planning, Sprint Review, and Sprint Retrospective) are also illustrated in Figure 3. If you are interested in understanding and implementing really effective Sprint Retrospectives, please take a look at my Making-sprint-retrospectives-really-effective blog on the subject.

As shown in Figure 3, I recommend that the analysis of backlog items for the next sprint should be scheduled on a regular cadence, where a two-hour meeting is held on every Wednesday (3 PM to 5 PM), as an example.  In these two meetings in a two-week sprint (a total of 4 hours or approximately 5% of the time in the two-week timebox), the product owner and the entire team converse about each story and also confirm each story with its acceptance criteria.  If the product owner cannot answer some questions in the meetings, he/she has adequate time left in the two-week sprint timebox to get those questions answered in consultation with users, customers and stakeholders, without blocking any team member.

I also recommend that the product owner grooms the product backlog and prepares a draft of backlog items for the next sprint on a regular cadence, shown on every Tuesday (3 PM to 5 PM) in Figure 3.  The cadence or pattern for sprint planning, sprint review, sprint retrospective, analysis for the next sprint, and product backlog grooming (shown in Figure 3) is for illustrative purposes only.  Your team should discuss and experiment various sprint cadence options to find the cadence that most suits your needs and choose the cadence that best works for you.  For example, a team may hold Sprint Review and Retrospective for the previous Sprint on Week-1 Monday morning (9 AM to Noon)  followed by Sprint Planning Workshop for the current sprint from 1 PM to 5 PM.  Another team may start the Timebox on a Wednesday (instead of Monday), and two weeks later end it on a Tuesday (instead of Friday), i.e., stagger the start and end of the timebox shown in Figure 3 by two work days to avoid Sprint Planning, Sprint Review and Sprint Retrospective falling adjacent to a weekend day (and tempting some team members to miss them due to their long weekend vacation!).

Regular cadence for all the activities mentioned above minimizes coordination, scheduling and transaction costs; increases predictability through a disciplined schedule published ahead of time for several release cycles (6 to 12 months), and helps an agile team to become a well-oiled machine.  Regular cadence or pattern also reduces unplanned, unexpected, interrupt-driven work that is very damaging due to sudden, unplanned context switches with resulting loss of productivity.

For all these activities shown on a regular cadence in Figure 3, the ScrumMaster working with the team members must set aside adequate capacity: 4 hours for sprint planning, 4.5 hours for 9 Daily Scrum meeting (preparation and attendance), 4 hours for Analysis of the next sprint, 3 hours for Sprint Review, Sprint Retrospective and Celebration – a total of 15.5 hours of capacity is needed for each member for these activities, and that capacity for each member is not available for the design-development-testing-defect fixing work for the current sprint.  If you are interested in calculating the agile capacity of a team after allocating capacity for all these activities, please see my Agile-capacity-calculation blog on the subject.

Solution to the challenge of managing the risk of doing wasteful work (2CP): An important reason why teams fail to deliver stories or backlog items in a sprint is that they were not understood properly when they were committed to the sprint plan during Sprint Planning.  As Dean Leffingwell explains in his Agile Software Requirements book (page 211), from a timing perspective there are three opportunities to do this conversation and confirmation for each story.

  • Prior to the sprint: This is what I have advocated in this blog by stipulating to engage in this conversation and confirmation only one timebox ahead.  Doing it more than one timebox ahead will increase the risk that some of those stories may not get into any sprint commitment as they get trumped by higher priority stories, or they may be removed from the product backlog altogether due to changed business conditions.
  • During the Sprint Planning Workshop:  This workshop is limited to approximately 4 hours for a two-week sprint.  In this short time box, the team has to not only converse and confirm the stories, but do story effort estimation and all other tasks related to sprint planning.  The team may find it difficult to get the time needed to complete the conversation and confirmation for each story, or the product owner simply may not have answers to some of the questions and most likely there is no time in the workshop timebox (only 4 hours) to get the answers by contacting users, customers and stakeholders.
  • During the actual sprint: If the team feels sufficiently confident that conversation and confirmation about a story can wait until the actual sprint due to uncertainty about the story’s business needs, then the conversation and confirmation for that story may be completed along with its implementation in the actual sprint if the story is of sufficiently lower priority.   However, keep in mind that the story was committed to the sprint during its sprint planning without proper conversation and confirmation (and hence with either no estimate or a very rough estimate).  This situation carries some risk and is not ideal.

I recommend that you complete the analysis of as many high priority stories as possible one timebox ahead of the sprint in which they will be implemented, try to complete as much analysis as possible for some of the lower priority stories during the Sprint Planning Workshop, and leave very small number of analysis questions to be resolved during the actual sprint if you have to.

In my coaching engagements, I have seen agile teams transitioning from sequential sprint execution model to the pipelined sprint execution model after 2 to 4 sequential sprints under their belt, and then with experience (inspect and adapt) getting better at the pipelined model.  This is kaizen (continuous improvements) in work, resulting into higher throughput, improved quality, and increased team morale and work satisfaction.

Have you tried the sprint pipelined model?  What is your experience?
Are you interested in starting your own sprint pipeline?

I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

 

Categories: Companies

Healthy Planning with Physicians Mutual

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

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

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

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

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

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

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

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

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

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

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

Hannah Shain
Categories: Companies

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

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

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

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

Paper set 550809 01 small

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

Instance Members: Death By 1,000 Paper Cuts

My first solution was to have ScheduleItem inherit from EventEmitter.

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

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

Dependency Injection: One Paper Cut 1,000 Times

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

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

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

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

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

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

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

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

Prototypes: Neosporin For My Paper Cuts

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

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

— Dave Mosher (@dmosher) April 10, 2014


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

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

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

Problem Solved!

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

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

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

     Related Stories 
Categories: Blogs

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

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

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

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

Your feedback is invited!

Categories: Blogs

It’s MAD to Use Discovery to Justify the Solution

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

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

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

Categories: Blogs

How Timelines Help Project Managers Track Progress

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

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

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

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

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

burn down chart

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

Timelines tracking for many projects

Work items in several projects on a timeline in Targetprocess 3

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

Timeline-by-Team

A teams/projects timeline in Targetprocess3

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

User Stories inside Features on a timeline in Targetprocess 3

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

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

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

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

Related articles:

How Visualize: Board, List or Timeline?

Why Visualize?

Categories: Companies

Without Simplicity, There Is no Agility

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

Agilia, Budapest, Hungary, June 11-13 2014

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

Yet Another $163B Waterfall Disaster

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

Knowledge Sharing


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