Skip to content

Feed aggregator

Regional Scrum Gathering Rio, Rio de Janeiro, Brasil, July 6-8 2017

Scrum Expert - Fri, 05/19/2017 - 11:00
The Regional Scrum Gathering in Rio de Janeiro is the largest Scrum event in Latin America. In the past, this Agile conferences taking place in Brazil received about 500 people and discussed topics...

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

Agile Israel, Tel Aviv, Israel, June 20 2017

Scrum Expert - Fri, 05/19/2017 - 10:00
Agile Israel is a one-day conference that discusses Agile, Scrum and Lean topics. It aims to attract Agile Managers, Scrum Masters, Product Owners and Coaches to discuss and network around these...

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

Cycle Time and Lead Time

Our organization is starting to talk about measuring Cycle Time and Lead Time on our software engineering stories.  It's just an observation, but few people seem to understand these measurement concepts, but everyone is talking about them.  This is a bad omen...  wish I could help illustrate these terms.  Because I doubt the measurements will be very accurate if the community doesn't understand when to start the clock, and just as important - when to stop it.

[For the nature of confusion around this terms compare and contrast these:  Agile Alliance Glossary; Six Sigma; KanbanTool.com; Lean Glossary.]

The team I'm working with had a toy basket ball goal over their Scrum board...  like many cheep toys the rim broke.  Someone bought a superior mini goal, it's a nice heavy quarter inch plastic board with a spring loaded rim - not a cheep toy.  The team used "Command Strips" to mount it but they didn't hold for long.

The team convinced me there was a correlation between their basketball points on the charts and the teams sprint burndown chart.  Not cause and effect, but correlation; have you ever stopped to think what that really means?  Could it mean that something in the environment beyond your ability to measure is an actual cause to the effect you desire?

I asked the head person at the site for advice, how could we get the goal mounted in our area?  He suggested that we didn't need permission, that the walls of the building were not national treasures - we should just mount it... maybe try some Command Strips.  Yes, great minds...  but what about getting fired after putting holes in the walls scares one from doing the right thing?  How hard is it to explain to the Texas Work Force Commission when they ask why you were fired?

The leader understood that if I asked the building facilities manager that I might get denied - but if he asked for a favor... it would get done.  That very day, Mike had the facilities manager looking at the board and the wall (a 15-20 minute conversation).  Are you starting the clock?  It's Dec 7th, lead time starts when Mike agreed to the team's request.

The team was excited, it looked like their desire was going to be granted.  Productive would flourish again.

Over the next few days I would see various people looking up at the wall and down at the basketball goal on the floor.  There were about 4 of these meetings each very short and not always the same people.  Team members would come up to me afterwards and ask...  "are we still getting the goal?"... "when are they going to bring a drill?"...  "what's taking so long?"

Running the calendar forward a bit... Today the facilities guy showed up with a ladder and drill.  It took about 20 minutes.  Basketball goal mounted (Dec 13th) - which clock did you stop?  All of the clocks stop when the customer (team) has their product (basketball goal) in production (a game commences).

I choose to think of lead time as the time it takes an agreed upon product or service order to be delivered.  In this example that starts when Mike, the dude, agreed to help the team get their goal mounted.

In this situation I want to think of cycle time as the time that people worked to produce the product (mounted goal) - other's might call this process time (see Lean Glossary).  And so I estimated the time that each meeting on the court looking at the unmounted goal took, plus the actual time to mount  the goal (100 minutes).  Technically cycle time is per unit of product - since in the software world we typically measure per story and each story is some what unique - it's not uncommon to drop the per unit aspect of cycle time.

Lead time:  Dec 13th minus Dec 7th = 5 work days
Cycle time:  hash marks //// (4)  one for each meeting at the board to discuss mounting techniques (assume 20 m. each); and about 20 minutes with ladder and drill;  total 100 minutes

Lead Time 5 days; Cycle Time 100 minutes
This lead to a conversation on the court - under the new goal with a few team members about what we could do with these measurements.  How if one's job was to go around and install basketball goals for every team in the building that a cycle time of 100 minutes with a lead time of 5 days might make the customers a bit unhappy.   Yet for a one off, unusual once a year sort of request that ratio of 100 minutes to 5 days was not such a bad response time.  The customer's were very happy in the end, although waiting for 5 days did make them a bit edgy.

But now what would happen if we measured our software development cycle time and lead time - would our (business) customers be happy?  Do we produce a once in a year product? (Well yes - we've yet to do a release.) Do our lead times have similar ratios to cycle time, with very little value add time (process time)?

Pondering...

Well it's January 5th and this example came up in a Scrum Master's Forum meeting.  After telling the tale we still did not agree on when to start and stop the two watches for Lead Time and Cycle Time.  Maybe this is much harder than I thought.  Turns out I'm in the minority of opinions - I'm doing it wrong!

Could you help me figure out why my view point is wrong?  Comment below, please.

LeanKit just published an article on this topic - it's very good but might also misinterpret cycle time.  I see no 'per unit' in their definition of cycle time.  The Lead Time and Cycle Time Debate: When Does the Clock Start? by Tommy Norman.

An Experiment in measuring the team's cycle time:
After a bit of time reflecting, debating, arguing with colleagues and other agilitst online I've decided to publish a little experiment in measuring cycle-time on a scrum team.  Here's the data... what does it say?  How do you think the team should react?  What action should be next?  What should the team's leadership feel/think/do?

The Story:  This team has been working together for a while.  The sprints are numbered from the start of the year... an interesting practice, this team uses 2 week sprints, is practicing Scrum.  Took a nice holiday and required some priming to get back in the swing of things after the first of the year (you see this in the trend of stories completed each sprint).  Cycle Time for a story on trend is longer than the sprint, this correlates with typical story "carry-over" (a story started is not finished in one sprint and is carried over to the next sprint).  Generally a story is finished in the sprint but not in sequence or priority - they all take at least the full sprint to get to done.  There is no correlation of story size to cycle time.

Now those are the facts more or less -- let us see what insights we might create from this cycle time info.  With no correlation of story size to cycle time AND little consistency of number of stories finished in a sprint (trend of # of stories: 1, 6, 7, 2, 2). The question arrises - what is the controlling variable that is not being measured that effects the time it takes to get from start to finish with a story?  Now that the team can see that the simplest things we could track do not have a strong effect on the length of time (or the through-put) a story requires... and that means the process is not under good control - we can start to look around for some of the uncontrolled (invisible factors) -- if we a courageous enough!

We reflected that many of the stories that carry over and are virtually unpredictable in size/time/effort appear to have large delays or multiple delays within their implementation phase.  So we devised a quick and dirty way to track this delay.  The assumption that this delay inherent in the work will perhaps be the unmeasured / uncontrolled variable that throws the correlation of story size with cycle-time out of kilter.

Our devised technique for tracking delay per story - a yellow dot on the task with a tick mark for every day the task is stuck in-process (delayed).




If this article spawns another article which references this one that references that one... does the internet cause a singularity?  I'd ask you to click this link, but you may implode:  Derek Wade - On Time.

See Also:

LeanKit published this excellent explanation of their choices in calculating cycle time within their tool:  Kanban Calculations: How to Calculate Cycle Time by Daniel Vacanti.
LeanKit Lead Time Metrics: Why Weekends Matter
Elon Musk turns a tweet into reality in 6 days by Loic Le Meur
The ROI of Multiple Small Releaseshttps://en.wikipedia.org/wiki/Frank_Bunker_Gilbreth_Sr.
https://en.wikipedia.org/wiki/Cheaper_by_the_Dozen


The Hummingbird Effect: How Galileo Invented Timekeeping and Forever Changed Modern Life
by Maria Popova.  How the invisible hand of the clock powered the Industrial Revolution and sparked the Information Age.

Categories: Blogs

They are “Lessons to be Learned”, not “Lessons Learned”

Leading Answers - Mike Griffiths - Thu, 05/18/2017 - 18:10
The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the... Mike Griffiths
Categories: Blogs

Targetprocess v.3.11.3: User Stories will now follow their parent Feature

TargetProcess - Edge of Chaos Blog - Thu, 05/18/2017 - 08:01
User stories will now follow their parent Feature

Previously, if you moved a Feature to another Project, its User Stories did not follow the Feature to the new Project. This was fairly counter-intuitive. Starting with this release, if you move a Feature to a different Project, all of its User Stories will follow (as long as they were originally in the same Project as their parent Feature).

If you move a Feature to a Project with a different process, you will get a warning that this change might cause you to lose some custom fields.

screen-shot-2017-05-17-at-5-48-21-pm

Private Impediments have been removed

As described in this blogpost, we're removing this barely-used feature to improve performance and reduce complexity. Feel free to message our support team if you have any questions.

Fixed Bugs
  • Corrected the @user mention format for email notifications
  • Fixed the creation of a Test Plan with multiple Test Cases via REST API POST
  • The order of mandatory custom fields in Quick Add forms will now correspond to their order in entity views
  • Fixed a case where it was not possible unlink a Bug from a Test Case Run if its Test Plan Run is the child of another Test Plan Run
  • Improved the performance of Relations lookup
  • Fixed an incorrect term: When completing Team Iterations, the system would incorrectly describe them as Iterations.
Categories: Companies

Staying on Course With Agile

Leading Agile - Wed, 05/17/2017 - 23:22

You may have heard that agile is just a bunch of cowboy programmers doing whatever they want; there is no rigor or discipline and best of all…NO more documentation. You may have heard about the agile zealots and that teams are full of these so called “agilistas” just spewing out code with no concern for quality and that you never know when anything is going to get done. You may have heard that others have tried some form of ‘agile’ and that “it” doesn’t work. Well fake news is everywhere these days, and misinformation about what agile is, and the notion that agile doesn’t work is a prime example.

The emotional reactions to agile can range from ‘meh’ to a vitriolic ‘it’ll never work here’. But, for organizations that are enthusiastic about making a transition and infusing more agility into their businesses, it is important to filter out the hyperbole. The facts can set you free. Becoming more agile is a journey rather than a destination, and in many ways, the path can be non-intuitive and overgrown with detritus.

Clear requirements have traditionally been an important first step to understanding the solution space and, just as importantly, an idea of how long it will take to implement it. There is a bit of hubris in this approach. Experience has shown that trying to nail down requirements at the beginning of a project—when we know the least about it—is the worst time to do so. What teams need instead is the ability to learn what a customer is trying to take care of throughout the project and make course corrections based on that emerging knowledge as it grows. Engendering the skill of making course corrections is one of the keys to the agile kingdom.

Experiments, and designing for discovery helps teams stay on course and produce better outcomes than big requirements documents and a lot of up front design. A well-groomed backlog is essential, but it does not mean that every detail is understood and articulated up front. Determining how to implement the details of a solution at the last responsible moment is encouraged because great solutions are based on the most up to date information about what is really needed rather than what we thought was needed at the outset of the project. Balancing when that information is captured and converted into team knowledge is a big differentiator between “doing Agile” and being agile.

That does not mean we don’t do any up front planning and certainly does not mean “No Documentation”. Themes, Initiatives, Epics and Stories all need elaboration and some form of memorialization so that teams can gain some collective knowledge around the outcomes that are going to be most important to customer. That documentation may be concise, and it may continue to be elaborated throughout delivery, but it should be captured in some way that communicates both the what and the why of the effort. The outcomes a customer is after is more valuable to understand than features or functionality. Requirements documents historically focus on the latter.

Far from the misperception that agile lacks discipline, done well, it is actually more rigorous than traditional approaches. Prioritization around value is not just the first step to a series of predetermined steps, but rather an ongoing guiding force as we continually refine our course toward the ultimate destination. Like an airplane navigating to Tokyo, pushed off course by winds and sometimes circumnavigating around bad weather, constant course correction produces a better result than setting a direction and hoping nothing changes along the way.

In a way, IT Leadership reminds me of my flying days. From checklists to navigation charts, pilots need documentation too. They need to know the radio frequencies with which to communicate and the protocols for doing so. And the good pilots are rigorous; they are disciplined. Now, there are some cowboy pilots out there who eschew the rules. Sometimes, unfortunately, they end up serving as a cautionary tale for others. There is an old saying about pilots, and I think it applies to IT leaders as well.

There are old pilots and there are bold pilots, but there aren’t any old, bold pilots!

So, rigor, communication and even documentation really are necessary. The best pilots have a lot of airtime and experience. They are most likely to get you safely to your destination. Indeed, for IT leaders, with large IT projects, there are similarities to flying a plane. Communication as well as both the skill of navigating and course correcting—are essential.

There are both cowboy pilots and cowboy agilistas out there. IT projects and flying can be inherently dangerous, and like so many failed IT projects, there are a plethora of failed agile experiments too. My recommendation in both cases is to look for experience. If you are considering agile, don’t listen to the “fake news”. Find a seasoned agile guide; someone with an approach that considers your environment, your business model and your customers and flexes to help you make the most of your transformation. Experience matters and the success of your journey may just ride on who you’ve chosen to help you navigate the course.

The post Staying on Course With Agile appeared first on LeadingAgile.

Categories: Blogs

GitKraken Tips V

About SCRUM - Hamid Shojaee Axosoft - Wed, 05/17/2017 - 20:03

Here is a roundup of our most recent 11 tips to help you become a bit more productive when you’re working. If this series is new to you, check out our previous tip roundups.

GitKraken Tips
  1.  Instantly open your current repo in a terminal window with alt/option + t, or from the File menu.
  2.  Push changes and start a pull request with one action. If you don’t have an upstream set, you’ll be prompted to set one first.
  3. Remote avatars in the graph help you see who is working on a branch. Get more info by hovering over those and other icons.

  4. The “Viewing” count displays how many branches/tags are visible in the graph. Quickly show all hidden items with “Show All”.
  5. Store HTTP & Proxy credentials to save time when pushing to remotes. They can be cleared in Preferences > Authentication
  6.  Create project groups in the new repo management view to keep your repositories organized.
  7. Open the Command Palette (cmd/ctrl + shift + p) or Fuzzy Finder (cmd/ctrl + p) and arrow down to see a list of shortcuts.

  8. You can drag-and-drop ref labels in the graph to merge, rebase, reset, etc. Multiple refs on one commit will expand on hover. 
  9. Pro users can create and switch between multiple profiles, each with unique settings and hosting service account integrations. 
  10. GitKraken’s easy-to-use conflict tool is even more powerful with Pro, giving you the ability to edit and save the output. 
  11. Hover icons on ref labels to view PR numbers and titles. Right-click the label for options to open them on GitHub.com.
Categories: Companies

Scrummish to Scrumban

Scrum Expert - Wed, 05/17/2017 - 16:42
Shoddy software quality, disgruntled customers, missed deadlines… Such is daily life in many software companies. But there exists a better way. This presentation tells a story of turning around...

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

Deprecating TestTrack integration

TargetProcess - Edge of Chaos Blog - Wed, 05/17/2017 - 15:37

Did you know we have an integration with TestTrack? Probably not. It's a legacy plugin – a really old one – from Targetprocess 2 that connects to the TestTrack bug tracking tool and periodically synchronizes defects from TestTrack with bugs in Targetprocess. Even the research we did in 2008 indicated that it was the least used plugin of all, but now its usage is even lower since it's only available for On-Premises installations (we removed it from On-Demand accounts about 6 years ago).

We haven't added much functionality to the plugin over the last decade, but we still had to keep it as part of the code base (which we're working on reducing), maintain automatic tests, and so on.

It's very possible that this will not affect anyone reading this post, but it's still a formal part of the software and needs a special announcement. So yes, starting with Targetprocess v.3.11.4, integration with TestTrack will no longer exist. 

This the part where I'm supposed to say something nice, maybe even dramatic about this feature... but I can't really think of anything. Sorry. Anyway, our code will be a little bit lighter and developers will be a little bit happier, so that's good news, even if it's minor.

Categories: Companies

Agile Movement's parallels to Lincoln's Gettysburg Address

What parallels are there between Lincoln's Gettysburg Address and the state of the Agile movement's union?

Lincoln was a primary figure at the dedication of Soldiers' National Cemetery, in Gettysburg. He did not wish to upstage the keynote speaker, Edward Everett, and so summarized in 2 minutes the principle of human equality as defined by the Declaration of Independence and the Civil War.  Do you remember, the keynote speech?  Few people do.


Lincoln's Gettysburg Address:
Four score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal. Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. But, in a larger sense, we can not dedicate—we can not consecrate—we can not hallow—this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth. - - U.S. President Abraham Lincoln
I heard an NPR story about a person that give their grandkids twenty dollars to recite the Address.  It sounded like a wonderful way to engage kids in history and the founding reasons of the existence of this nation.  I'm assuming that it would take the children some time to memorize the short speech and in so doing they would have questions, about what the words meant.  How many of your colleagues know what unit of quantity a score represents?  Do you know what happened four-score and seven years before 1863?

The foundational document of this new nation is the Declaration of Independence - signed in the summer of 1776 by a group of wealth white men.  They are now described as our founding fathers, yet some were quite young at the time (Hamilton, 21; Jefferson, 33; Washington, 44).  These free thinking people (and some were women - they just didn't sign the document) were called radicals by their government and traders by their neighbors.


Does any of this sound like a fractal of the Agile Manifesto and the movement that was started back in the 1990s with lightweight frameworks for organizing software product creation.  The desire to increase the good aspects and there by overcome the poor habits (appreciative inquiry or extreme programming - is there a difference?).

Is there a revisionist movement some 15-20 years beyond the 2001 manifesto creation?  Yes, there appears to be a constant yearning for the next wave, the next wagon to hitch your cart onto.

Are there amendments that need to be added to the manifesto much like the Bill of Rights?  Or is that a fringe movement on the periphery?



Modern agile  defining four guiding principles:

  • Make people awesome
  • Make safety a prerequisite
  • Experiment and learn rapidly
  • Deliver value continuously

Alistair Cockburn observer his communication style in beginner and advanced classes, he said: "[I] found that when I was encouraging getting back to the center/heart/spirit of agile, I kept emphasizing these four things, and drew them in a diamond:"



Could the newest technique Mob Programming be anything more than an incremental addition to eXtreme Programming (XP)?  Some 30 years in the making.








I've found a next movement in the Agile Symphony. [Do you see what I just did there? Yeah, changed the metaphor but pivoted upon the term movement. Crafty right?]  I believe the next movement that so many people are looking for are just a jump to the left.  Look to the left of the typical process flow of value through the company, just left of what the current Agile process addresses (software development).  It's the creative process that is just up stream of software development.  The product ideation phase, the place where all those creative people are trying to get a seat at the table and be engaged with the software product design.  The User Interface and User eXperience people are wanting to engage with the whole process. Not just be consulted at the end of the process when the user acceptance test has proven that no one wants to use our product.

Could it be that the UX group is searching for a way to improve the development process?  Are they sensing the need to find a better process?  One that results in similar outcomes but with shorter timelines, a process that allows them to maximize the value in their portion of the stream.  I think this group is in the same place as the lightweight software development group was in the 1990s.  Before a few of them got together to coin the term Agile and write a manifesto to protect their small market share from the large 800 pound gorillas in the software consultancy market space.

Well the gorillas have exerted their power and the industry has consolidated into the safer methods that allow the late adopters to feel good about their failing transformations.  Your OK, and I'm OK; let's just call the whole thing off.  And that folks, is how we arrive back at the trend in business lifecycles becoming shorter, while innovation continues to accelerate.

So maybe this new movement in the symphony will allow me to come into their community.  I feel I have something to offer, I love learning, and building (which I think of as design).  I have a bit of experience with these new methods of designing and building and learning as we discover what the customer truly desire.  I'd like to help the creative people get that seat at the whole development table.

Maybe you could think of this period of software development as the reconstruction.

See Also:

Reshaping our View of Agile Transformation - Jason Little

Categories: Blogs

The Career Path of a Scrum Master

I blogged recently on the question of whether a Scrum team can ever get so good that they no longer need a Scrum Master. In this post, I’ll address a closely related topic: Assuming that the role of Scrum Master does not go away, what is the career path for a Scrum Master?

In my experience, a Scrum Master’s career will usually evolve in one of four directions.

Multiple and More Challenging Teams

A typical career path for a Scrum Master will start with serving one team. After a while that team becomes less time-consuming to work with, as issues are resolved and the team takes on more responsibilities itself.

At that point, a good Scrum Master will seek additional challenges. Often the logical next step is to begin working with multiple teams concurrently or from working with more demanding teams or products.

When developing new Scrum Masters, I prefer to put the person in a position to most likely succeed. That will means working with a team that has neither any difficult personalities nor unrealistic delivery expectations. But, to go from good to great, the Scrum Master will need to learn to work under more complex conditions.

This leads to the philosophy that success is often rewarded with additional challenges.

Mentor

A Scrum Master who has been successful in a variety of different contexts and teams, might choose to move into a role as a mentor to other Scrum Masters. This will especially be true and feasible as the Scrum Master gains skills and experience.

In many organizations, this role would be called an Agile Coach, with the most common job description being that an agile coach coaches Scrum Masters (and their teams).

Personally, I’m partial to such individuals mentoring rather than just coaching. Much of the benefit these experienced individuals provide comes through them offering guidance (“I suggest you do it this way”). Because of this, I think of these individuals as having become agile mentors.

This is an appropriate path for Scrum Masters who have learned that their true passion is the creative act of developing a product--largely independent of whatever the product may be. Some Scrum Masters enjoy the process of enabling creativity among development teams so much that it almost doesn’t matter what the product is.

Think about the radio DJ who just loves being a DJ and doesn’t care if he’s playing classic rock, the current top 40, or classical music.

The Scrum Master who loves the process more than the product is a likely candidate to follow a career path into becoming an agile coach or mentor.

The Scrum Master Becomes a Product Owner

Other Scrum Masters, however, learn that they love what their team is building more than the act of creating it. Those Scrum Masters become good candidates to become product owners.

I don’t want to imply that a product owner role is above the Scrum Master role in an organization. I consider the roles equivalent in a typical organizational hierarchy.

But some Scrum Masters learn that they care deeply about the thing being built rather than the process of building the thing. And from having worked with a team long enough, some of these Scrum Masters learn enough about the product, industry, users and such to become good product owners.

The Scrum Master Becomes a Manager

Scrum Masters are most assuredly not managers themselves. But through their Scrum Masters duties, Scrum Masters often work closely with those who are. And some will find that work intriguing.

Scrum Masters become adept at guiding teams without much authority to say, “Do it because I say so.” Because of this, many can move into management roles where they could demand compliance but because of what they’ve learned from being Scrum Masters, know it usually is best not to.

Especially if a Scrum Master has retained technical proficiency, moving into a role like QA director or development manager can be a fulfilling, logical step.


Scrum Masters often become coaches, mentors, product owners, managers or continue as Scrum Masters in more challenging situations.

A Scrum Master Has Options

There are many paths a Scrum Master may pursue. The skills learned in becoming a great Scrum Master will serve that person well whether they choose to become a mentor, manager, product owner or just work with more challenging teams.

In some ways, asking what is the career path for a Scrum Master is like asking what is the career path of a professional athlete.

Some professional athletes use their former careers as springboards to move into broadcasting. Others use the money they’ve made to start businesses--where I live in Colorado, car dealerships and pizza restaurants seem popular with retired athletes. Some athletes use their fame to enter politics.

Still other professional athletes would find the topic of a career path preposterous. They didn’t become athletes as a path to something else. Becoming a professional athlete was the goal itself.

And so it will be for many Scrum Masters. The role of Scrum Master can be an end itself. Doing it more and better can remain the goal. A professional athlete cannot perfect his or her sport. A Scrum Master cannot perfect that skill either. There is always room to improve. And so, for many Scrum Masters, there may be no career path other than the continuous improvement in themselves that Scrum Masters demand of their teams.

Where Are You Headed?

If you’re currently a Scrum Master, what do you think is next for you? If you were formerly a Scrum Master, what you done since leaving that role? Please share your thoughts in the comments below.

Categories: Blogs

Visual Reports: Formulas Editor Change

TargetProcess - Edge of Chaos Blog - Tue, 05/16/2017 - 15:20
Invalid formulas and old-style report formulas will not be saved

We have disabled the ability to save invalid and previous version graphical report formulas .

formula

You can use special functions if you need to create reports using the formulas from previous version of graphical reports.

  1. RAW_TEXT(<Targetprocess DSL text expression>) for text or boolean formulas. For example:
    RAW_TEXT("Test")
  2. RAW_NUMBER(<Targetprocess numeric expression>) for numeric formulas. For example:
    RAW_NUMBER(Int32.Parse("45"))
  3. RAW_DATE(<Targetprocess date expression>) for using text or boolean formulas. For example:
    RAW_DATE(DateTime.Parse("3 September"))
  4. RAW_ARRAY_TEXT(<Targetprocess text array expression>) for using text or boolean formulas. For example:
    RAW_ARRAY_TEXT(AssignedEfforts.Select(Assignable.Name))

     

We will really appreciate your feedback on our reports editor. What do you like about it? What could be improved? Let us know what you think at ux@targetprocess.com

Categories: Companies

Why Splitting Unfinished Product Backlog Items is a Bad Idea

Scrum Expert - Tue, 05/16/2017 - 10:33
In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that...

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

Service Desk updates: Color Themes and Request Type improvements

TargetProcess - Edge of Chaos Blog - Tue, 05/16/2017 - 09:39

It's been awhile since we posted about our progress on Service Desk. We have just released several nice features that we'd like to share with you.

Color themes

You can now change the look of your Service Desk by picking from one of the predefined color options. This is the first step to making the colors fully customizable and allowing you to use your company colors in addition to your logo.

sd_color_schema

If you'd like to customize something other than color, please share the details with us. This will help us make sure we don't miss anything important, while hopefully not over-complicating everything under the hood.

Disabling votes

Previously, the "Vote" button was available for any request type, which did not always make sense. You don't typically need someone to upvote your browser crashing issue or something like that, right? So you can now define which request types will have the Vote button, and which will have it removed.

You can configure voting at Targetprocess Settings -> Request Types.

request_type_options

Default visibility

We've received a fair amount of feedback along the lines of "why can't I make all requests public" or "the new request type is always private". Since you can already create your own request types, we decided to make it more flexible. When submitting a new request, the "Private" check-box will either be checked or not, depending on what you select at Settings. Users, however, will still be able to change the visibility (depending on the particular request).

You can configure default visibility at Targetprocess Settings -> Request Types.

default-visibiliy

Fixed bugs

We also fixed a number of bugs and made some internal changes. Among the most noticeable are:

  • State grouping: states before the 'Planned' state are no longer added to the 'In Progress' group.
  • Fixed half a dozen IE-specific bugs (or should we say, we made Service Desk more compliant with the bugs of Internet Explorer?).
  • Fixed the order of custom fields at the Add Request page. It is now updated automatically when you reorder them in Targetprocess.
Please note that the changes above require Targetprocess version 3.11.2. If you are hosting Service Desk locally using IIS, you will also need to update .Net Core to 1.1. See our guide for more info.
Categories: Companies

Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination

NetObjectives - Mon, 05/15/2017 - 21:43
Note: This blog assumes the reader understands the basic roles and practices of Scrum. Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (product owner, team, scrummaster) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an...

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

Version R6#14.13

IceScrum - Fri, 05/12/2017 - 17:58
R6#14.13 Here is the new and probably the last version of iceScrum R6. Its only purpose is providing iceScrum Standalone R6 users with the ability to migrate their projects to iceScrum v7. If you use iceScrum Cloud, you will have to wait a little longer before the migration is available but don’t worry it’s our…
Categories: Blogs

Design Your Competition's Support Department

You are presented with a common business problem.  One technique that has always helped me to define the problem space is to invert the problem, take it to an extreme to explore the continuum of your domain.  Let's imagine that we want to redesign our software support department at MegaSoft Corporation.  Applying our inversion principle we will leave our MegaSoft support as is, and instead we will design the competitors support group. It's going to stink, people are going to hate to even call them, their people will be arrogant techies with no human compassion - they will actually hire with those skills required.  Let's pause and give this company a name...  TechHard sounds great.

Who's time is most valuable?  At TechHard the support engineers time is very valuable, so we will have process that time how long a support tech. is on the call with a customer so that our process gurus can optimize for the use of this most valuable resource.  A typical call from a director or VP in our internal support operation should be logged by an administrative receptionist (maybe even automated system) and then the support techs time can be queued up with return call tickets.  We will return the VPs call when it is convenient for our tech.  The tech can validate that the VP is authorized to access the system, and will confirm that they are still experiencing the problem by walking through a standard checklist.  Being efficiently minded the tech may skip over some simple question like power plug, on/off, reset/reboot, logout/in again if they feel the user is competent.


Answering the basic question of who's time is most valuable via the design of the competition's process is enlightening.  Which is it?  The support person's time - or the customer's time.

How are support systems designed?  Has anyone ever heard of a company that used Design Thinking or High-Tech Anthropology to create a customer centered support group?

Is this Conway's Law at work - are we truly designing the support function of our products/services - or are we just reacting?

Give me an example of great design for support:  Nest Thermostat and Fire Alarm Installation
Have you installed a Nest product?  Their installation and configuration process is well designed.  I don't know about their support department - but my expectations are set very high, if I have a problem.


History will repeat
In the 1980s universities started teaching about design for manufacturing (robots would make the parts).

Are you designing your business departments for it's function?

Speaking of support tools - your going to want a great issue tracking system.  Why not look to a market leader that has all the features your people can put on a check list?  Let's buy Jira - or should we look at the competition's product?



See Also:

Cable Internet provider Frontier's support group struggles with the corporate infrastructure that can not resolve customer problems.







Categories: Blogs

Can we have a dialogue about Estimation and the behaviors it drives?


Some topic are taboo - not safe to discuss.  I've never appreciated that concept.  Those taboo topics are my favorite topics to discuss.

Taboo Topics (ordered by fear of conversation)
  • Gender - Sexual preferences - non-standard practices
  • Religion as truth, my religion vs your wrong religion
  • Politics - the correct way to govern a group the results in my opportunity
  • Pay for services rendered - why my gender is paid more than yours
  • counting - off by one errors and how to mask them; we're # 1
  • estimates - how wrong your estimate was and why I'm missing my commitment
  • prioritization - ordering methods
  • laziness - the art of not doing work
I've recently been embroiled in a "dialogue" about the twitter topic of #NoEstimates.  I would write a summary of the topic but cannot do better that this one:

Estimates? We Don’t Need No Stinking Estimates! by Scott Rosenberg
"How a hashtag (#NoEstimates) lit the nerdy world of project management aflame — or at least got it mildly worked up."

A nice summary of the dust-up.  Imagine if the tag would have been #LeanEstimates?

There are two sides to this debate - at least two sides.  But I like that the taboo topic was raised and has questioned assumptions.  I think the think that drives a topic toward the taboo is this questioning of assumptions.  The saluter of scared cows (where does that term even come from?).

So what behaviors does the process or estimating drive:


  • a list
  • TBD
  • someone misplaced the list...


"Unable to estimate accurately, the manager can know with certainty neither what resources to commit to an effort nor, in retrospect, how well these resources were used.  The lack of a firm foundation for these two judgements can reduce programming management to a random process in that positive control is next to impossible. This situation often results in the budget overruns and schedule slippages that are all too common." -- J.A FarquharDoes a Scrum process framework and the Agile mindset resolve Farquhar's concerns that the manager may have without accurate estimates - via empirical measurement and relative estimation techniques?

I'm not sure that the Twitter-verse is capable of holding the dialogue.  My experience was not very fruitful nor enlightening.  I've been accused by a manager at work of being "anti-management" I've asked, but got no direct answer, what that term meant, and why he believed or thought this label to be useful.  I've wondered if it was because of this type of conversation.  I also asked these fellows, but didn't resolve my query with the rhetoric of the conversation.
@vishalsomal it's an anti-management movement started by Woody, where SWDev wants to run the show @PeterKretzman @henebb pic.twitter.com/lPxrYNDg9n— Glen B. Alleman (@galleman) March 5, 2017... deleted ... a lot of tweets about actions from years ago when when the #NoEstimates twitter conversation was beginning - some relating to a blog post being edited or complete deleted.  Something I find quite acceptable (and do quite frequently myself).
@henebb @PeterKretzman @galleman @duarte_vasco So if he deleted a piece you appear to object to maybe you made a point and he heard your view.— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco is it admirable to be the accuser but not reach out to talk,
to label one hyper-defensive when they are trying to understand? pondering— David A. Koontz (@davidakoontz) April 13, 2017
@PeterKretzman @davidakoontz @henebb @duarte_vasco David, U do realize W and V and now N blocked any questions about the credibility of #NE.
There is NO conversation about NE just broadcast— Glen B. Alleman (@galleman) April 14, 2017
@galleman @PeterKretzman @henebb @duarte_vasco 3 people do not make the sum total of people discussing this topic.— David A. Koontz (@davidakoontz) April 14, 2017
@davidakoontz @galleman @PeterKretzman @duarte_vasco Of course not. No one is claiming that either. But they are the main champs. Traveling the world, spreading the message.— Henrik Ebbeskog (@henebb) April 14, 2017
@galleman @PeterKretzman @henebb @duarte_vasco So I reject your conclusion; and substitute #NE or #noestimates with #LeanEstimates— David A. Koontz (@davidakoontz) April 14, 2017
The conversation went on from there...  I'm reminded of Adam on MythBusters.



@henebb @galleman @duarte_vasco I don't know if this anti-management you speak of. Tell me more as I don't see connection to NE or as we call it now #LeanEstimation— David A. Koontz (@davidakoontz) April 13, 2017 ... and there is some link to Anti-Management because one is willing to discuss better options or worse options than estimation...
@henebb Here's an anti-management tweet (one of many) from the NE founder. @davidakoontz @galleman @duarte_vasco pic.twitter.com/CdVrQxYOAz— Peter Kretzman (@PeterKretzman) April 13, 2017
@PeterKretzman @henebb @galleman @duarte_vasco Is it the answers or the questions you object to as being anti-management?— David A. Koontz (@davidakoontz) April 13, 2017
@PeterKretzman @henebb @galleman @duarte_vasco ... 2/2 because I'm willing to engage in dialogue about #NoEstimates in public? Is anti-management contagious? #LeanEstimates— David A. Koontz (@davidakoontz) April 13, 2017 There appears to be large amounts of animosity amongst the principle people that were having this dialogue - nope that word is not the best word, here... try debate... twitter shouting match...
@henebb @PeterKretzman @galleman @duarte_vasco well that certainly didn't happen, thanks to your vigilance; have you asked him if that was his intent?— David A. Koontz (@davidakoontz) April 13, 2017
@davidakoontz @henebb @galleman @duarte_vasco Point: Woody won't talk with critics.
Second point: you're a little too fixated on this one example of anti-mgmt. As I said, there are many.— Peter Kretzman (@PeterKretzman) April 13, 2017
@PeterKretzman @henebb @galleman @duarte_vasco So you didn't ask Woody about the issue?
Is it just you he will not talk to, because I've chatted with him a lot.— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco I like that analogy... estimate are addictive - but not that powery - what is your object to the analogy?— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco brushing teeth is not addictive; it's nothing like heroin addiction I'm told.— David A. Koontz (@davidakoontz) April 13, 2017
@davidakoontz @PeterKretzman @galleman @duarte_vasco ...Yeah, and seeing healthy estimating as "addiction process" reveals that you despise estimates.— Henrik Ebbeskog (@henebb) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco wow - how did you jump to that conclusion?
"despise estimates" not many of the team members I work with would support your conclusion— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco ah... do we need to review the concept of analogy - I liked the analogy, I find it useful; I think that's different than what your stating— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco that's not where I would apply the nature of addiction in the analogy. Yet I can see how you could get there.— David A. Koontz (@davidakoontz) April 14, 2017 How might the analogy of estimation is like addiction be a useful analogy?
@galleman @PeterKretzman @henebb @duarte_vasco That's not consistent with my conversation and experiences with @WoodyZuill (your good with logic - am I within the set of anyone?)— David A. Koontz (@davidakoontz) April 13, 2017
@PeterKretzman @henebb @galleman @duarte_vasco I'm just guessing but I bet there was a period when he was willing to converse with you all.
pondering ... my experience extrapolated ...— David A. Koontz (@davidakoontz) April 13, 2017


See Also:


Impact of Schedule Estimation on Software Project Behavior
by Tarek K. Abdel-Hamid, SRI International Stuart E. Madnick, Massachusetts Institute of Technology
A Preliminary Inquiry into the Software Estimation Process by J.A. Farquhar, 1970
Categories: Blogs

Agile Australia, Sydney, Australia, June 22-23 2017

Scrum Expert - Thu, 05/11/2017 - 09:00
Agile Australia is a two-day conference built specifically for Agile and Scrum practitioners in Australia who are serious about expanding their thinking and ways of working: at an individual and...

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

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.