Skip to content

Feed aggregator

Good Enough

Leading Agile - Mike Cottmeyer - Thu, 04/09/2015 - 15:10

Last week I was talking to the founder of a company regarding their ability to continue growing their existing products as well as creating an ability to innovate more quickly. One of the core challenges expressed in this conversation was the need to create fast feedback loops for new ideas. Driving innovation through the more predictable delivery capability was not providing the fast feedback needed and was creating disruption for the part of the organization charged with continuing to grow existing products.

It was clear that an innovation lab of some sort would remove those disruptions while allowing them to more quickly bring product ideas to market. The importance of gaining quick feedback on new product ideas was an important consideration. A challenge that kept coming up was that of building new capabilities that accomplish the goal of the requirements but are not really usable. In this particular industry, the capabilities provided must solve a problem but more importantly, do it in a way that is without friction and easy to understand in an instant.

coffe-cup-badAn analogy I used during this conversation was that we may have requirements to build a coffee cup that can hold 10 ounces and have a handle. The requirements are clear in what we need to deliver and we can do so. But, we can clearly create a coffee cup that meets the requirement but find that it is not usable…

It would be very helpful to introduce visual specifications in this instance. A quick visual that describes what the solution might look like would create alignment about what is being built and provide an ability to gain feedback on the usability of the solution. Had the visual above been used to discuss the specifications then we could quickly realize that though it does provide the ability to contain 10 ounces of liquid that can be carried easily, it doesn’t help with the need to drink from the cup.

coffee-cup-goodVisual specifications are a powerful way of increasing our understanding of requirements and increasingly help us determine if our intended solution will solve the problem and be usable. Visual specifications range from architectural diagrams, UI mock ups, and any visualization that can help us better understand requirements.

I will provide a bit of a warning, don’t go overboard with this. The visual specifications just have to be good enough. A picture of a whiteboard drawing is good enough. A screen capture with hand drawn changes are good enough. I’ve seen organizations spend more time creating visual specifications with high end tools than it would have taken just to build the working capability… Low fidelity visual specifications are what we’re after.

Visual specifications help create a richer language when communicating requirements. It improves collaboration and our ability to get feedback. If you’ve not tried this then I encourage you to do so and see if it keeps you from building unusable coffee cups.

The post Good Enough appeared first on LeadingAgile.

Categories: Blogs

News update 2015/04 – Kanban Foundation & Advanced Courses

ScrumSense.com - Peter Hundermark - Thu, 04/09/2015 - 12:58

We hope you all had a lovely Easter break!

Joanne Perold talks about “Managing Flow” in our latest blog post. So many organisations she works with have benefited from using this technique to improve how they do what they do. The blog post is also timely, as this is a key practice in Kanban, and Dr. Klaus Leopold will be coming to SA in May to provide two awesome two day courses on Kanban fundamentals, and scaling……more.

KANBAN FOUNDATION & ADVANCED COURSESKanban training

Dr. Klaus Leopold, of LEANability in Vienna, will be running the popular Applying Kanban (Foundation) and Improving & Scaling Kanban (Advanced) certified courses on the 04-05 May 2015 and the 07-08 May 2015 respectively.

The Applying Kanban (Foundation) course provides a deeper understanding of Kanban for knowledge workers. The focus is on practical learning based on concrete problems of the participants. If you are keen to begin your Kanban journey or have already introduced Kanban and want to verify if the implementation complies with state-of-the-art Kanban knowledge then this is the course for you.

Awesome course, very interactive and informative. Absolutely coming back for the Advanced course. Thank you Klaus. – Doug Crawford, Entelect

Knowledge-busting, mind blowing, exciting, enjoyable, practical, sensible, plain down awesome…a great course to be on! – Yusuf Desai, Derivco

The Improving & Scaling Kanban (Advanced) course teaches advanced principles of the Kanban Method. It is for people who have already mastered the Kanban basics and wish to learn more.

Please follow this link to find out more and to take advantage of our 3-for-2 special offer!

LEADING SELF-ORGANISING TEAMS COURSE

We are pleased to announce the dates for the next Leading Self-Organising Teams course. This course will be taking place on the 07-08 July 2015 in Johannesburg. Louise Gardiner, of First Principles, and Peter Hundermark have joined forces to bring you this masterclass.

Learn state-of-the-art tools and practices for Lean/Agile organisations in an interactive classroom-based environment. Ensure that your teams are focusing on the rights things in the right way and at the right time. Get equipped now to face the complex leadership challenges of the 21st century. Book your place today!

Scrum Coaching Retreat Cape TownSCRUM COACHING RETREAT CPT

The first Scrum Coaching Retreat held in South Africa in February 2015 was a great success. Participants gained valuable learnings and enjoyed mingling with like-minded people. An outcomes website was created as a central repository for participants to capture their outputs. Feel free to take a look at what the teams got up to!

Agile CI2I is an output of one of the teams. The website serves as a collaborative space for agile coaches to share their experiences, tips and resources in working with organisational leaders. Follow this link to get involved.

UPCOMING COURSES

Certified Scrum Master (CPT) – Fully booked!
13-14 Apr 2015
Steenberg Hotel, Cape Town

Applying Kanban (Foundation) – (JHB) – 3-for-2 Special!
04-05 May 2015
FNB Conference & Learning Centre, Sandton

Improving & Scaling Kanban (Advanced) – (JHB) – 3-for-2 Special!
07-08 May 2015
FNB Conference & Learning Centre, Sandton

Certified Scrum Master (JHB)
19-20 May 2015
FNB Conference & Learning Centre, Sandton

Course schedule and Book Online

The post News update 2015/04 – Kanban Foundation & Advanced Courses appeared first on ScrumSense.

Categories: Blogs

Managing Flow

ScrumSense.com - Peter Hundermark - Thu, 04/09/2015 - 10:19

My next blog post is about “Managing Flow”. So many organisations I work with have benefited from using this technique to improve how they do what they do. I also felt it timely, since this is a key practice in Kanban, and Klaus Leopold will be coming to SA in May to provide two awesome two day courses on Kanban fundamentals, and scaling.

Traditional project management teaches us to manage resources and dependencies. Making sure everyone is busy is important because our plan is based on people optimisation and cost accounting. Managing flow in Kanban is the opposite of this and therefore often counter-intuitive.

Managing flow is a principle of Kanban and is about shifting the focus from the people to the work. So instead of managing people and keeping them busy all the time, we focus on managing the work and understanding how we get that work through the system faster.

The distinction is very important.

How do you manage flow? Visualise

Well the first step to managing flow is to understand where all the work in the system (by system I mean a human system designed to deliver value to the business) is. You need to visualise the value stream, and then visualise all the work in that value stream. Your value stream is the flow of work through your system, from concept to cash or beginning to end. This often depends on the level of granularity of your Kanban system. A good way to do this is to use a physical board, and to map your process from beginning to end. How does work flow into your system and how does it leave.

Limit WIP

Once you have the visualisation of where the work is, you need to begin to limit the amount of work in progress. Why would you want to do that I hear you ask?

There are many reasons to limit work in progress:

  • Create focus and prevent context switching: The more work there is in a system, the less focus any piece of work is getting. Context switching has a massive transaction cost and means that any single piece of work can end up taking longer than if there was focus around getting it done.
  • Decrease batch size:  Smaller batches mean faster feedback and shorter lead times.
  • Decrease complexity: The more work there is in a system the more complexity there is. Things that are deployed on the test environment affect each other. You need to manage all the dependencies that are created and the communication efforts of many more people. This all adds complexity and the higher the complexity the greater the risk.
  • Enable flow: The more work there is in a system, the more it will look like rush hour traffic and the less flow there will be. At 5:00pm in Sandton all the buildings in a four block area empty at the same time. The result of this is that the road infrastructure can’t handle the capacity and the roads become blocked and gridlocked. The same happens in software teams, and human systems when they have too much work in progress. By limiting the work in progress you can enable much better flow of work through the system.
Show blockages

Focusing on where the work is in a system, can help us have better conversations about which piece of work is the most important and where we need to spend our energy. It can also help us to see what is getting stuck. When something is stuck we want to visualise that. We want to understand first of all why it is stuck and second of all we want to make sure that our energy is focused on getting it unstuck. The tendency in systems designed for people optimisation is that the person whose current task is blocked by others will simply start on the next piece of work. The problem with this is that often the work item that is stuck is far more valuable than the next work item. Another impact of this behaviour, is that the ‘blocker’ gets moved into the background and forgotten about. It’s easy to forget things like that when there are another hundred other items right behind the one that’s stuck. This also means that when the work becomes unstuck it ends up in a queue, and each queue will have an impact on lead times.

Continuous Improvement

Having the visualisation, the limited WIP and the blockages visible, will give you large amounts of information about how your system works and what is in the way of getting things done. This is now a great starting point for conversations on how your system and processes can be improved and what can be done to better enable the flow of work. Talking about the work and managing the work through the system, means that we are focused on delivering value faster rather than on keeping people busy.

Keeping people busy can lead to longer queues, larger batches, more complexity and longer lead times. Managing flow will create focus on delivering value faster, and uncovering the challenges that get in the way.

If you want to know more about this have a look at http://www.klausleopold.com/.

 

The post Managing Flow appeared first on ScrumSense.

Categories: Blogs

Do you have an Agile Testing mindset ?

Agile World - Venkatesh Krishnamurthy - Wed, 04/08/2015 - 23:13

Here is my recent guest post for Zephyr…

image Performing Testing in Agile projects is not termed as Agile testing. Agile testing involves whole different mindset.  Then, how do you know your team has Agile testing mindset?  As a coach, I start this by asking testers the following few questions:

- Do have to wait until the development is done to start testing?

- Do testers feel there is a lack of time at the end of Sprint?

- Are testers blamed when defects are identified?

If testers answer “Yes” to some or all the questions above, then the team still has “Waterfall” mindset in guise of Agile. 

Another litmus test to try is to check the team’s wall which is popularly called “Kanban” wall. If you see a wall like the one below, where the “Test” ing is a separate column, then this is a smell.

Read the rest of the article on Zephyr

image

Categories: Blogs

SonarQube User Conference – U.S. West (Santa Clara, CA)

Sonar - Wed, 04/08/2015 - 22:01

We are very happy to announce that the second SonarQube user conference will take place on April 27th at the Santa Clara Convention Center, in Santa Clara, California.

Following our East Coast tour in October of last year and the good feedback we received from it, we have decided to host another event, this time on the West Coast. This time the format will be slightly different, with two distinct sessions:

  1. An executive session in the morning covering major topics on our roadmap, as well as strategy, adoption, and results. This session is reserved to our customers.
  2. A more technical session in the afternoon, during which we will demonstrate the latest features, such as new integrations with Visual Studio and TFS, new bug detection features, issue filtering through Elastic Search… We will also discuss the challenges and future state of the SonarQube platform and Continuous Inspection as a practice.

We believe this is a unique chance for us to meet our users, and for you to provide feedback on the product and to hear where we are going, so we hope you’ll be able to join us.

There is still time to register but don’t wait too long; the seats are filling up fast! To reserve your seat, simply send an email to kristi.karu At sonarsource.com.

And if you can’t make it to California this spring, don’t worry. We’re planning a similar event this fall in Europe. Stay tuned for more details.

Categories: Open Source

Learning Opportunities for All

Johanna Rothman - Wed, 04/08/2015 - 20:10

If you are not on my Pragmatic Manager email list, you might not know about these opportunities to explore several topics with me this month:

An Estimation hangout with Marcus Blankenship this Friday, April 10, 2:30pm EDT. If you have questions, please email me or Marcus. See the Do You Have Questions About Estimation post. Think of this hangout as a clinic, where I can take your questions about estimation and help you address your concerns.

In the Kitchener-Waterloo area April 29&30, I’m doing two workshops that promise to be quite fun as well as educational:

  • Discovering the Leader Inside of You
  • An Agile and Lean Approach to Managing Your Project Portfolio

To see the descriptions, see the KWSQA site.

You do not have to be a manager to participate in either of these workshops. You do need to be inquisitive and willing to try new things. I believe there  is only room for two people for the leadership workshop. I think there is room for five people in the project portfolio workshop. Please do sign up now.

 

Categories: Blogs

3 Reasons IT Ops Uses Lean Flow (Kanban for DevOps part 3 of 3)

In this three-part series on Kanban for DevOps, Dominica DeGrandis, Director of Training and Coaching at LeanKit, explains three key reasons why IT Ops teams and those implementing a DevOps value chain use a lean flow approach to product development. If you’re just jumping in to this series, check out part one and part two. Reason […]

The post 3 Reasons IT Ops Uses Lean Flow (Kanban for DevOps part 3 of 3) appeared first on Blog | LeanKit.

Categories: Companies

New CEO for the Scrum Alliance

Scrum Expert - Wed, 04/08/2015 - 16:30
The Scrum Alliance has announced that it has named Manuel Gonzalez as its new Chief Executive Officer (CEO). This is the first time Scrum Alliance has appointed a CEO and signifies the organization’s increasing scale and ambition as it seeks to guide organizations to be prosperous and sustainable through the use of Scrum. “Scrum Alliance’s Board of Directors had many discussions about the search for a CEO and the skills we felt a good candidate would need to fill the role,” said Harvey Wheaton, Scrum Alliance Chairman of the Board. ...
Categories: Communities

Lebst du schon oder arbeitest du noch?

Scrum 4 You - Wed, 04/08/2015 - 08:12

Zum Thema Work-Life-Balance gibt es so viele Meinungen und Ideen, wie es Menschen gibt. Meistens gehen diese Meinungen davon aus, dass Arbeit und Leben zwei unterschiedliche Sphären sind. Viele Autoren vertreten die Ansicht, dass Arbeit generell so stressig ist, dass man sich davon erholen muss. Auf den ersten Blick haben sie recht: Die erfolgreichen Menschen Ende 20, Anfang 30 sind extrem belastet. Für den Erfolg im Beruf wird von ihnen viel erwartet: Überstunden sind an der Tagesordnung, Familie und Freunde müssen mit den hinteren Plätzen Vorlieb nehmen. In einem Artikel auf Elite Daily ist zu lesen, man solle sich daher den Arbeitgeber aussuchen, der zu den persönlichen Vorstellungen von Work-Life-Balance passt. Das ist eine schöne Idee, aber ich muss widersprechen.

Natürlich sollte man grundsätzlich darüber nachgedacht haben, ob man reisen will, welche Arbeitsbelastung man akzeptieren kann und wozu man bereit ist. Das tut man auch, wenn man erkennt, dass täglich genügend Zeit mit Pferd, Hund und Katze wichtiger ist als alles andere, oder dass die allabendliche Kneipentour mit Freunden einfach sein muss. Vielleicht reicht dazu ein Job, um finanziell über die Runden zu kommen – ohne jeglichen Anspruch auf Karriere oder täglich neue Herausforderung. Ich selbst habe Tennisplätze gebaut, Bonbons abgepackt und jahrelang als Krankenpfleger gejobbt (was man am niedrigsten Level als Hilfspfleger tatsächlich machen kann – die Profession der vollumfänglichen Krankenpflege zu erlernen dauert hingegen Jahre). Lauter Jobs, deren Aufgaben man mit ein wenig Einsatz leidlich erlernen kann. Meine Berufung waren diese Jobs aber sicher nicht. Was ein Beruf wirklich erfordert, können nur jene verstehen, die sich längere Zeit mit einem Beruf auseinandersetzen.

Fokus macht den Meister

Wer also nicht nur einen Job zum Geldverdienen suchen, sondern seine Berufung finden will, sollte sich bei allem Positiven an der Work-Life-Diskussion deutlich machen: Man kann nur in einer Sache richtig gut werden. Fokus ist das Gebot der Stunde. Um eine Sache oder einen Beruf intensiv zu erlernen und sich das Feld zu erarbeiten, braucht man einen starken Willen und Ausdauer. Gut zu werden braucht einigen Befunden zufolge etwa 10.000 Stunden oder zwischen 5 und 8 Jahren intensive Beschäftigung mit einer Profession. Wer schnell nachrechnen will: 10.000h/8 = 1.250 Tage; 1.250 Tage/5 Tage = 250 Arbeitswochen oder rund 5 Jahre. Über einen so langen Zeitraum den Fokus zu halten, erfordert sicher ein paar Opfer. Aber muss das zu Lasten der Familie oder des Körpers gehen? Müssen wir diese 10.000 Stunden so schnell wie möglich abarbeiten? Könnte es möglicherweise auch anders funktionieren? Ja – für den, der sich fokussiert. Für den, der sich einer Sache verschreibt, dranbleibt und für sich akzeptiert, dass lediglich Fortschritt, nicht Perfektion erreicht werden kann.

Pixabay

Pixabay

Fortschritt, nicht Perfektion

Die Young Professionals von heute ertragen das wesentlich schwerer als frühere Generationen. Soziale Netzwerke und die Medien gaukeln ständig vor, dass man zu langsam ist. Die 30-Jährigen von heute wollen eine Familie und erfüllte Beziehungen und Kinder und Freunde und gut aussehen und fit und sportlich sein. Nein – man muss sich nicht entscheiden, ob man das eine oder das andere will. Aber man muss sich fokussieren, einen Schwerpunkt setzen und das tun, was man wirklich tun will, denn: Wer etwas liebt, wird gut in dem, was er tut. Wer etwas gerne tut, wird freiwillig die eine oder andere Stunde mehr arbeiten. Weil es Spaß und Freude macht, erfüllend ist und nicht auslaugt. Wenn Michael Phelps seinen Sport nicht geliebt hätte, wäre er dann so weit gegangen, nicht nur fünf, sondern sieben Tage in der Woche zu trainieren? „From age 14 through the Beijing Olympics, Phelps trained seven days a week, 365 days a year. He figured that by training on Sundays he got a 52-training-day advantage on the competition. He spent up to six hours in the water each day. ‚Channeling his energy is one of his great strengths’, said Bowman. Not to oversimplify, but it’s not a stretch to say that Phelps channeled all of his energy into one discipline that developed into one habit—swimming daily.“ (Keller 2013, Pos. 586) Jeder von uns kennt dieses Gefühl, wenn man etwas gerne tut – man macht es länger und länger. Und natürlich gibt es auch jene Tage, an denen es keinen Spaß macht und man einfach nur durchhält. Wer etwas mit Erfüllung tut – und sei es der Beruf –, der hat auch Freunde, funktionierende Beziehungen und kann aktiv Sport treiben.

Beruf(ung) braucht Ausgleich

Was hat das nun alles mit der Wahl des richtigen Jobs (Verzeihung: Berufs) zu tun? Bei der Berufswahl geht es nicht darum, ob man die richtige Mischung aus Freizeit und Beruf gefunden hat. Es geht darum, einen Beruf zu finden, in dem man etwas tun kann, das man liebt und mit Begeisterung tun will. Wem das gelingt, der wird sich am Beginn vielleicht etwas verausgaben, weil es so viel Spaß macht. Aber schnell wird der- oder diejenige auch lernen, dass man sich auch noch um sich selbst kümmern muss. Dazu gehört es, einen Ausgleich zu suchen und Freunde zu finden, die diese Freude am Beruf auch aushalten. Wer sich fokussiert, wird im Beruf selbst wiederum lernen, bei einer Sache zu bleiben und sich nicht zu verzetteln. Dann bleibt Zeit für vieles andere. Ich selbst kann nur aus Erfahrung berichten, unsere Mannschaft macht es vor. Wir arbeiten viel und oft kommen das Sporttraining, der Freund oder die Familie etwas zu kurz. Aber wir machen unsere Arbeit , weil wir jeden Tag erleben dürfen, wie wirksam das ist, was wir tun. Wer sich wirksam (=mächtig im positiven Sinn) fühlt, der wird durch den Job gesund und nicht krank. Unsere Familien und Freunde erleben uns dann als erfüllt und zufrieden, nicht als gestresst. Arbeit und Leben sind keine Gegensätze, sondern ein Ganzes und das sollte es doch auch sein. Immerhin verbringen wir mit unserer Arbeit mindestens 8 Stunden täglich.

Literatur
Keller, Gary: The One Thing. The surprisingly simple truth behind extraordinary results. Kindle Edition. London: John Murray Press, Hodder & Stoughton, 2013.

Categories: Blogs

Features do not a Product Roadmap Make

Tyner Blain - Scott Sehlhorst - Tue, 04/07/2015 - 23:32

list of features

Last month, Mike Smart of Egress Solutions and I gave a webinar for Pragmatic Marketing on product roadmapping when working in agile environments. We had a great turnout of over 1500 people in the session – with not nearly enough time to answer all of the questions.

One attendee asked, “Please explain how a prioritized list of features is not a roadmap?

A fantastic question, which we did not see in time to answer during the call.

Why and What and When

The shortest answer I can come up with for the question – and probably all we would have had time to address during the call is the following:

A roadmap tells you both “why” and “what;” a list of features tells you only “what.” #prodmgmt

 

If all you need is the answer above, then this is a really short article for you – you can stop here.  There is some nuance to the above statement, which helps you address something more valuable – having a good roadmap.  If that’s interesting, then keep reading.

Which What?

Seven years ago this month, I joined in the fracas stirred up by an article where the author

  1. Described something (bad) which was not a roadmap
  2. Called it a roadmap, then
  3. Concluded that roadmaps are bad.

I would describe the author’s complaints [about roadmaps] as a list of things which can go wrong when you treat a list of features as if it were a roadmap.

Seven years later, this is still a source of confusion.  Perhaps it is the logical conclusion of anointing people with the title of “product manager” and not giving them the training, tools, and mentorship needed to learn the craft while simultaneously doing the work.

Some of the confusion may come from how we talk about roadmaps.  My tweetably short answer above leaves something to be desired.

Roadmap vs Backlog

All of the different containers for requirements document “what” the team will be building.  The different containers do this in different ways – and the roadmap has a qualifier.

  • PRD – identifies all the things which the team will build*, and the context in which those items are relevant or organized (e.g. the “Shopping Cart” section of the PRD for an ecommerce website will include the requirements for including controls that allow a user to update the quantity of items in the cart).
  • List of Features – possibly the most abhorrent of the containers – in the midst of a long list, will be the requirement to include an “update quantity” control with every item in the shopping cart.  If you’re lucky, the requirement will be tagged with “shopping cart” for ease of organizing / tracking progress.  Given the lack of context provided by a list of features, this requirement might be preceded by the “update inventory levels” requirement and followed by the “update user profile picture” requirement.
  • Backlog – when someone takes a list of features and sorts them by “give me this first” you get a backlog.  The story at the top of the list may be “As a [shopper in a hurry, who is multitasking while waiting in line at the DMV] I need to be able to update the quantity of items in my shopping cart because someone jostled me and I double-tapped my phone when I meant to single-tap, so that I only purchase the quantity I intended.” The question too many people are happy to dodge is why is this story at the top of the list? We’ll have to come back to that another time.
  • Roadmap – “Yes, but” is consultant speak for “I’m answering your question, but let me tell you the question you should have asked – and the answer to that question as well.” If your roadmap says “Will include update quantity control in shopping cart” you’re doing it wrong.  Your roadmap should say “Improved shopping experience on mobile” or “Better shopping experience for spearfisher  persona.” Those descriptions of “what” are at a higher level, and articulate intentionality.  So, yes, a roadmap includes “what” – but not the same “what” as a backlog.

*As an aside – the team won’t actually build all of the stuff in the PRD, nor will they build what they build when the PRD says it will happen, and it will be over-budget.  But that’s another discussion entirely – and a big part of why “agile” came into existence in the first place.

When a roadmap is being used to communicate “what” the product will be, it should be in the language of describing which problems will be addressed, for whom, or in what context.  This is the most important type of theme which would be part of a thematic roadmap.  Other themes could be “improve our positioning relative to competitor X” or “fill in a missing component in our portfolio strategy.”

Context in Design

Requirements, by their nature, live in a particular context.  At one elevation or perspective, something is a requirement, defining and constraining what must be done; in a different context, that same something is a design choice representing a choice about how to do what must be done.

Several months ago, Andy Polaine posted a presentation about the future of UX, in which he presented a compelling imagery establishing the context in which design decisions are made.

Andy Polaine context slide

To fully appreciate the power of what Andy is talking about, I believe you have to view the above slide (#55), in the context of his presentation.  After experiencing it that way, the imagery has infused itself into how I frame product management activities.

If you cannot make time for now, the metaphor still works – solving the “visible and available” problem happens in the context of a wider environment (a larger, more complex problem), which is itself in the context of a wider environment, etc.

I find that I also apply the same concept when thinking about investments across differing time horizons.

On a given day, a member of the product team is implementing the code for adjusting the quantity of an item in the shopping cart.  Implementation is not the rote mechanical movements of a machine – it is a series of choices and actions.

Those implementation decisions happen within the context of implementing a story from the top of the backlog – helping someone place orders on their phone while waiting in line somewhere.  This context informs choices (like not requiring a modal dialogue to confirm the user’s choice when making a change in quantity, or making the change to “quantity of zero” be an explicit and distinct interaction).

The decision to prioritize empowering mobile users this quarter comes within the context of a decision to focus on 18 to 26 year olds as a key demographic for our product sales.  Improvements to the mobile shopping experience happen in conjunction with a change in inventory, a partnership with another company, and a targeted advertising campaign.

The focus on this particular group of customers is a “business design” choice as well.

Context in Agile A backlog lives within a roadmap, it does not replace it #agile #prodmgmt

 

A similar perspective on context is presented by Mike Cottmeyer of Leading Agile when looking at how you put the work the teams are doing into context. A “release backlog” or “product backlog” is defined within the context of strategy – which is manifested in the roadmap.

strategic agile context

Mike’s slide (#92 in a great deck) stops with “strategic” context for a release.  He and I have talked about this, and I believe we have strikingly similar views on context.  This view marries both the time-horizon and the problem-definition notions of context, from the perspective of the person doing the work and understanding the “why” of doing the work.

Within each context is framed a set of choices – providing both boundaries and flexibility to adapt to what we learn, but at a lower level of detail, with less ultimate potential value, for a shorter period of time.

Conclusion

A backlog – a prioritized list of features – is not a roadmap.  It is a reflection of a set of design choices which happen to fulfill in product what the roadmap sets out as a manifestation of strategy.

A roadmap tells you both “why” and “what;” a backlog tells you only “what.” #agile #prodmgmt
Categories: Blogs

Neo4j: The learning to cycle dependency graph

Mark Needham - Tue, 04/07/2015 - 22:59

Over the past couple of weeks I’ve been reading about skill building and the break down of skills into more manageable chunks, and recently had a chance to break down the skills required to learn to cycle.

I initially sketched out the skill progression but quickly realised I had drawn a dependency graph and thought that putting it into Neo4j would simplify things.

I started out with the overall goal for cycling which was to ‘Be able to cycle through a public park':

MERGE (:Goal:Task {name: "Be able to cycle through a public park"})

This goal is easy for someone who’s already learnt to cycle but if we’re starting from scratch it’s a bit daunting so we need to break it down into a simpler skill that we can practice.

The mini algorithm that we’re going to employ for task breakdown is this:

  1. Can we do the given task now?
  2. Break the task down into something simpler and return to 1.

One of the things to keep in mind is that we won’t get the break down perfect the first time so we may need to change it. For a diagram drawn on a piece of paper this would be annoying but in Neo4j it’s just a simpler refactoring.

Going back to cycling. Since the goal isn’t yet achievable we need to break that down into something a bit easier. Let’s start with something really simple:

MERGE (task:Task {name: "Take a few steps forward while standing over the bike"})
WITH task
MATCH (goal:Goal:Task {name: "Be able to cycle through a public park"})
MERGE (goal)-[:DEPENDS_ON]->(task)

In the first line we create our new task and then we connect it to our goal which we created earlier.

Graph  9

After we’ve got the hang of walking with the bike we want to get comfortable with cycling forward a few rotations while sitting on the bike but to do that we need to be able to get the bike moving from a standing start. We might also have another step where we cycle forward while standing on the bike as that might be slightly easier.

Let’s update our graph:

// First let's get rid of the relationship between our initial task and the goal
MATCH (initialTask:Task {name: "Take a few steps forward while standing over the bike"})
MATCH (goal:Goal {name: "Be able to cycle through a public park"})
MATCH (goal)-[rel:DEPENDS_ON]->(initialTask)
DELETE rel
 
WITH initialTask, goal, ["Get bike moving from standing start", "Cycle forward while standing", "Cycle forward while sitting"] AS newTasks
 
// Create some nodes for our new tasks
UNWIND newTasks AS newTask
MERGE (t:Task {name: newTask})
WITH initialTask, goal, COLLECT(t) AS newTasks
WITH initialTask, goal, newTasks, newTasks[0] AS firstTask, newTasks[-1] AS lastTask
 
// Connect the last task to the goal
MERGE (goal)-[:DEPENDS_ON]->(lastTask)
 
// And the first task to our initial task
MERGE (firstTask)-[:DEPENDS_ON]->(initialTask)
 
// And all the tasks to each other
FOREACH(i in RANGE(0, length(newTasks) - 2) |
  FOREACH(t1 in [newTasks[i]] | FOREACH(t2 in [newTasks[i+1]] |
    MERGE (t2)-[:DEPENDS_ON]->(t1) 
)))
Graph  10

We don’t strictly need to learn how to cycle while standing up – we could just go straight from getting the bike moving to cycling forward while sitting. Let’s update the graph to reflect that:

MATCH (sitting:Task {name: "Cycle forward while sitting"})
MATCH (moving:Task {name: "Get bike moving from standing start"})
MERGE (sitting)-[:DEPENDS_ON]->(moving)

Graph  11

Once we’ve got the hang of those tasks let’s add in a few more to get us closer to our goal:

WITH [
  {skill: "Controlled stop using brakes/feet", dependsOn: "Cycle forward while sitting"},
  {skill: "Steer around stationary objects", dependsOn: "Controlled stop using brakes/feet"},
  {skill: "Steer around people", dependsOn: "Steer around stationary objects"},
  {skill: "Navigate a small circular circuit", dependsOn: "Steer around stationary objects"},
  {skill: "Navigate a loop of a section of the park", dependsOn: "Navigate a small circular circuit"},
  {skill: "Navigate a loop of a section of the park", dependsOn: "Steer around people"},
  {skill: "Be able to cycle through a public park", dependsOn: "Navigate a loop of a section of the park"}
 
] AS newTasks
 
FOREACH(newTask in newTasks |
  MERGE (t1:Task {name: newTask.skill})   
  MERGE (t2:Task {name: newTask.dependsOn})
  MERGE (t1)-[:DEPENDS_ON]->(t2)
)

Finally let’s get rid of the relationship from our goal to ‘Cycle forward while sitting’ since we’ve replaced that with some intermediate steps:

MATCH (task:Task {name: "Cycle forward while sitting"})
WITH task
MATCH (goal:Goal:Task {name: "Be able to cycle through a public park"})
MERGE (goal)-[rel:DEPENDS_ON]->(task)
DELETE rel

And here’s what the final dependency graph looks like:

Graph  13

Although I put this into Neo4j in order to visualise the dependencies we can now query the data as well. For example, let’s say I know how to cycle forward while sitting on the bike. What steps are there between me and being able to cycle around a park?

MATCH (t:Task {name: "Cycle forward while sitting"}),
      (g:Goal {name: "Be able to cycle through a public park"}),
      path = shortestpath((g)-[:DEPENDS_ON*]->(t))
RETURN path

Graph  14

Or if we want a list of the tasks we need to do next we could restructure the query slightly:

MATCH (t:Task {name: "Cycle forward while sitting"}),
      (g:Goal {name: "Be able to cycle through a public park"}),
      path = shortestpath((t)<-[:DEPENDS_ON*]->(g))
WITH [n in nodes(path) | n.name] AS tasks
UNWIND tasks AS task
RETURN task
 
==> +--------------------------------------------+
==> | task                                       |
==> +--------------------------------------------+
==> | "Cycle forward while sitting"              |
==> | "Controlled stop using brakes/feet"        |
==> | "Steer around stationary objects"          |
==> | "Steer around people"                      |
==> | "Navigate a loop of a section of the park" |
==> | "Be able to cycle through a public park"   |
==> +--------------------------------------------+
==> 6 rows

That’s all for now but I think this is an interesting way of tracking how you’d learn a skill. I’m trying a similar approach for some statistics topics I’m learning about but I’ve found the order of tasks isn’t so linear there – interestingly much more a graph than a tree.

Categories: Blogs

Why I Write

Thought Nursery - Jeffrey Fredrick - Tue, 04/07/2015 - 22:27

I’m on Day #2 of the 10 Days to a Better Blog online workshop and the assignment for today  is to meditate and write down the answer to your “why” in terms of your writing, and they even provided a nice template for the content that I’m happy to adopt as my own.

I’m beginning to define and explore the difficult question of why I write and why I want to become a better writer. Here are some of my initial and incomplete thoughts:

  • I aim to reduce suffering in the world of software development through improved practices and improved communication. I believe that the practices and mindsets that make a difference can be taught, and I believe that through writing down what I’ve learned I can reach a wider audience than I do through my working and speaking and meetup activities.

I feel that’s fairly complete. I’ve given a lot of thought over the years to my purpose, my mission, my Why. And thus in the Why | How | What scheme described by Simon Sinek, writing is a How, not a Why.

How to get better at writing? That’s something I’m still working on…

Categories: Blogs

Stop ‘teaching’ students about entrepreneurship…!

Manage Well - Tathagat Varma - Tue, 04/07/2015 - 19:07
Last weekend, I was at one of the youngest IIMs - IIM Udaipur to be a mentor at their annual event Prarambh where students and young entrepreneurs slog for 32 non-stop hours to build a 'startup'. No, not just a cool code hack but a (near-real) startup. The event ends with the teams pitching to real VCs. And who knows what can happen there...
Categories: Blogs

Clean Tests: Database Persistence

Jimmy Bogard - Tue, 04/07/2015 - 18:13

Other posts in this series:

A couple of posts ago, I walked through my preferred solution of isolating database state using intelligent database wiping with Respawn. Inside a test, we still need to worry about persisting items.

This is where things can get a bit tricky. We have to worry about transactions, connections, ORMs (maybe), lazy loading, first-level caches and more. When it comes to figuring out which direction to go in setting up a test environment, I tend to default to matching production behavior. Too many times I’ve been burned by bizarre test behavior, only to find my test fixture/environment doesn’t match against any plausible or possible production scenario. It’s one thing to simply and isolate, it’s another to operate in a bizzaro world.

In production environments, I deal with a single unit of work per request, whether that request is a command in a thick client app, a web API call, or a server-side MVC request. The world is built up and torn down on every request, creating a lovely stateless environment.

The kicker is that I often need to deal with ORMs, and barring that, some sort of unit of work mechanism even if it’s a PetaPoco DB object. When I set up state, I want nothing shared between that setup part and the Execute step of my test:

Each of these steps is isolated from the other. With my apps, the Execute step is easy to put inside an isolated unit of work since I’m using MediatR, so I’ll just need to worry about Setup and Verify.

I want something flexible that works with different styles of tests and not have something implicit like a Before/After hook in my tests. It needs to be completely obvious “these things are in a unit of work”. Luckily, I have a good hook to do so with that Fixture object I use to have a central point of my test setup.

Setup

At the setup portion of my tests, I’m generally only saving things. In that case, I can just create a helper method in my test fixture to build up a DbContext (in the case of Entity Framework) and save some things:

public void Txn(Action<MyContext> action)
{
    var dbContext = new MyContext();
    DbContextTransaction txn  = null;
    try
    {
        txn = dbContext.Database.BeginTransaction();
        action(dbContext);
        dbContext.SaveChanges();
        txn.Commit();
    }
    catch (Exception)
    {
        txn?.Rollback();
        throw;
    }
}

We create our context, open a transaction, perform whatever action and commit/rollback our transaction. With this method, we now have a simple way to perform any action in an isolated transaction without our test needing to worry about the semantics of transactions, change tracking and the like. We can create a convenience method to save a set of entities:

public void Save(params object[] entities)
{
    Txn(dbContext =>
    {
        foreach (var entity in entities)
        {
            var entry = dbContext.ChangeTracker
                .Entries()
                .FirstOrDefault(entityEntry => entityEntry.Entity == entity);

            if (entry == null)
            {
                dbContext.Set(entity.GetType()).Add(entity);
            }
        }
    });
}

And finally in our tests:

public InvoiceApprovalTests(Invoice invoice,
    [Fake] IApprovalService mockService,
    IInvoiceApprover invoiceApprover,
    SlowTestFixture fixture)
{
    fixture.Save(invoice);

We still have our entities to be used in our tests, but they’re now detached and isolated from any ORMs. When we get to Verify, we’ll look at reloading these entities. But first, let’s look at Execute.

Execute

As I mentioned earlier, for most of the apps I build today requests are funneled through MediatR. This provides a nice uniform interface and jumping off point for any additional behaviors/extensions. A side benefit are the Execute step in my tests are usually just a Send call (unless it’s unit tests against the domain model directly).

In production, there’s a context set up, a transaction started, request made and sent down to MediatR. Some of these steps, however, are embedded in extension points of the environment, and even if extracted out, they’re started from extension points. Take for example transactions, I hook these up using filters/modules. To use that exact execution path I would need to stand up a dummy server.

That’s a little much, but I can at least do the same things I was doing before. I like to treat the Fixture as the fixture for Execute, and isolate Setup and Verify. If I do this, then I just need a little helper method to send a request and get a response, all inside a transaction:

public TResult Send<TResult>(IRequest<TResult> message)
{
    var context = Container.GetInstance<MyContext>();
    var mediator = Container.GetInstance<IMediator>();
    DbContextTransaction txn = null;
    TResult result;

    try
    {
        txn = context.Database.BeginTransaction();
        result = mediator.Send(message);
        txn.Commit();
    }
    catch (Exception)
    {
        txn?.Rollback();
        throw;
    }

    return result;
}

It looks very similar to the “Txn” method I build earlier, except I’m treating the child container as part of my context and retrieving all items from it including any ORM class. Sending a request like this ensures that when I’m done with Send in my test method, everything is completely done and persisted:

public InvoiceApprovalTests(Invoice invoice, 
    [Fake] IApprovalService mockService,
    SlowTestFixture fixture)
{
    fixture.Save(invoice);

    A.CallTo(() => mockService.CheckApproval(invoice.Id)).Returns(true);

    fixture.Send(new ApproveInvoiceCommand {InvoiceId = invoice.Id});

My class under test now routes through this handler:

public class ApproveInvoiceHandler : RequestHandler<ApproveInvoiceCommand>
{
    private readonly MyContext _context;
    private readonly IInvoiceApprover _invoiceApprover;

    public ApproveInvoiceHandler(MyContext context,
        IInvoiceApprover invoiceApprover)
    {
        _context = context;
        _invoiceApprover = invoiceApprover;
    }

    protected override void HandleCore(ApproveInvoiceCommand message)
    {
        var invoice = _context.Set<Invoice>().Find(message.InvoiceId);

        _invoiceApprover.Approve(invoice);
    }
}

With my Execute built around a uniform interface with reliable, repeatable results, all that’s left is the Verify step.

Verify

Failures around Verify typically arise because I’m verifying against in-memory objects that haven’t been rehydrated. A test might pass or fail because I’m asserting against the result from a method, but in actuality a user makes a POST, something mutates, and a subsequent GET retrieves the new information. I want to reliably recreate this flow in my tests, but not go through all the hoops of making requests. I need to make a fresh request to the database, bypassing any caches, in-memory objects and the like.

One way to do this is to reload an item:

public void Reload<TEntity, TIdentity>(
    ref TEntity entity,
    TIdentity id)
    where TEntity : class
{
    TEntity e = entity;

    Txn(ctx => e = ctx.Set<TEntity>().Find(id));

    entity = e;
}

I pass in an entity I want to reload, and a means to get the item’s ID. Inside a transaction and fresh DbContext, I reload the entity and set it as the ref parameter in my method. In my test, I can then use this reloaded entity as what I assert against:

public InvoiceApprovalTests(Invoice invoice, 
    [Fake] IApprovalService mockService,
    SlowTestFixture fixture)
{
    fixture.Save(invoice);

    var invoiceId = invoice.Id;

    A.CallTo(() => mockService.CheckApproval(invoiceId)).Returns(true);

    fixture.Send(new ApproveInvoiceCommand {InvoiceId = invoiceId});

    fixture.Reload(ref invoice, invoiceId);

    _invoice = invoice;
}

In this case, I tend to prefer the “ref” argument rather than something like “foo = fixture.Reload(foo, foo.Id)”, but I might be in the minority here.

With these patterns in place, I can rest assured that my Setup, Execute and Verify are appropriately isolated and match production usage as much as possible. When my tests match reality, I’m far less likely to get myself in trouble with false positives/negatives and I can have much greater confidence that my tests actually reduce bugs.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Putting Some Numbers on Technical Debt

Scrum Expert - Tue, 04/07/2015 - 14:53
Technical debt is one of this great new metaphor that is applied to software development and more specially to agile project management approaches like Scrum. As its financial counterpart, technical debt is not necessary a bad thing as long as you are able to manage it wisely. In this article, Don Reinertsen will help you to put some numbers on the costs and benefits of your technical debt. The article starts by discussing the technical debt metaphor and assessing the difference with financial debt. As Don Reinertsen wrote it: “When we ...
Categories: Communities

Scrum is about Daily Planning, not Daily Status

Scrum 4 You - Tue, 04/07/2015 - 08:24

One of my main appreciations for Scrum stems from the fact that every role has clear responsibilities:

Product Owner – his product’s ROI (Return on Investment)
ScrumMaster – his team’s productivity (hence: master of the process)
Development Team – quality and delivery

Scrum asks the Development Team to meet in front of its task board once a day in a meeting called the Daily Scrum and answer four questions:

  • What have I done since yesterday?
  • What will I be doing today?
  • Where do I need help?
  • Is anything impeding my process?

I am not happy with the simplicity of these four questions anymore, as I am encountering too many teams that have fallen into their trap. It seems that they are leading teams to thinking as individual warriors battling through their own jungle of tasks. However, the Daily Scrum is supposed to get rid of individual status reports and move towards planning as a team.

Now how do we do turn a status meeting into an actual planning meeting?

Consider this: you as a Development Team are responsible for the quality and the delivery of your product. You know that the Daily Scrum is a short daily planning meeting in order to achieve your sprint commitment in the best possible way considering your responsibilities. If I were a Development Team member, I would simply change the standard four questions to:

  • What have I done (preferably together with another team member to ensure quality and know-how transfer) since yesterday to finish the user story with the highest business value and thus get closer to our sprint commitment?
  • What will I be doing today (preferably together with another team member to ensure quality and know-how transfer) to finish the user story with the highest business value and thus get closer to our sprint commitment?
  • How can we as a team work together today in order to get the best out of our skills and deliver a product whose quality will make our users proud?
  • Is anything whatsoever hindering or stopping me in order to use my skills and know-how in the best possible way to further my team’s delivery?

Yes, these questions may be longer. Yes, they will take some teams a little bit of time to get used to.

However, I believe that the answers to these questions are the real reason why teams should spend 15 minutes of each day in front of their task board to talk about their shared delivery and the quality of their product increments.

Try it out. Let me know what you think.

Categories: Blogs

Rolling upgrade of Docker applications using CoreOS and Consul

Xebia Blog - Mon, 04/06/2015 - 22:17

In the previous blog post, we showed you how to setup a High Available Docker Container Application platform using CoreOS and Consul. In this short blog post, we will show you how easy it is to perform a rolling upgrade of a deployed application.

Architecture

In this blog post we will use the same architecture but for the deployment we used Vagrant instead of Amazon AWS which is a little bit snappier to use  :-).

coreos-vagrant-cluster

In the Vagrant architecture we have replaced the AWS Elastic Load Balancer with our own consul-http-router Load Balancer and moved it inside the cluster. This is a HA proxy which dynamicly routes traffic to any of the http routers in the cluster.

Getting Started

In order to get your own container platform as a service running on vagrant, clone the repository and start your cluster.


git clone https://github.com/mvanholsteijn/coreos-container-platform-as-a-service.git
cd coreos-container-platform-as-a-service/vagrant
vagrant up
...
vagrant up
Bringing machine 'core-01' up with 'virtualbox' provider...
Bringing machine 'core-02' up with 'virtualbox' provider...
Bringing machine 'core-03' up with 'virtualbox' provider...
...
Checkout the cluster

After the cluster has started, you can use the following command to checkout whether your cluster is fully operational. You should see 6 units running on each machine.

for node in 1 2 3 ; do
  vagrant ssh -c "systemctl | grep consul" core-0$node
done
...
consul-http-router-lb.service loaded active running consul-http-router-lb
consul-http-router.service loaded active running consul-http-router
consul-server-announcer.service loaded active running Consul Server Announcer
consul-server-registrator.service loaded active running Registrator
consul-server.service loaded active running Consul Server Agent

 

Deploying the application

Once the cluster is running, you can deploy or paas-monitor application. This happens in two stages. First you submit the template.

fleetctl submit paas-monitor\@.service

Then, you load and start the new instances.

fleetctl load paas-monitor\@{1..6}.service
fleetctl start paas-monitor\@{1..6}.service
fleetctl list-units | grep paas-monitor

You can now see the paas-monitor in operation on your machine by opening http://paas-monitor.127.0.0.1.xip.io:8080 and clicking on start.  You should see something like shown in the table below. Leave this running while we are going to update the application!

host release message # of calls avg response time last response time 47ea72be3817:1337 v1 Hello World from v1 53 8 11 cc4227a493d7:1337 v1 Hello World from v1 59 11 8 04a58012910c:1337 v1 Hello World from v1 54 7 6 090caf269f6a:1337 v1 Hello World from v1 58 7 7 096d01a63714:1337 v1 Hello World from v1 53 7 9 d43c0744622b:1337 v1 Hello World from v1 55 7 6 Updating the application

Now we are going to update your application. Normally, we would expect that you specify a higher version of the Docker image into unit file. But instead of changing the version of the image to be executed change the value of the environment variable RELEASE in the unit template file  paas-monitor\@.service.

sed -i -e 's/--env RELEASE=[^ ]*/--env RELEASE=v2/' paas-monitor\@.service

Now we have changed the unit template file, you should destroy the old unit file and submit the new one.

fleetctl destroy paas-monitor\@.service
fleetctl submit paas-monitor\@.service

Now you have two options, a slow one and a fast one.

Slow Option

The slow option is to  iterate over the running instances, stop them one by one, destroy them and start a new instance based on the newly submitted template. Because this is boring, repetitive work we have created a small script that does this :-)


./rolling-upgrade.sh paas-monitor\@.service

Fast Option

The fast option is to start 6 new ones and stop all 6 old ones after the new ones are running.

fleetctl load paas-monitor\@1{1..6}.service
fleetctl start paas-monitor\@1{1..6}.service
fleetctl list-units | grep 'paas-monitor\@1[1-6].service' | grep running
fleetctl stop paas-monitor@{1..6}.service
fleetctl destroy paas-monitor@{1..6}.service

When you watch your monitor, you should see the new instance appear one by one.

host release message # of calls avg response time last response time 47ea72be3817:1337 v1 Hello World from v1 53 8 11 cc4227a493d7:1337 v1 Hello World from v1 59 11 8 04a58012910c:1337 v1 Hello World from v1 54 7 6 090caf269f6a:1337 v1 Hello World from v1 58 7 7 096d01a63714:1337 v1 Hello World from v1 53 7 9 d43c0744622b:1337 v1 Hello World from v1 55 7 6 fee39f857479:1337 v2 Hello World from v2 18 7 9 99c1a5aa3b8b:1337 v2 Hello World from v2 2 7 9 Conclusion

CoreOS and Consul provides all the basic functionality to manage your Docker containers and perform rolling upgrade of your application.

 

Categories: Companies

Introducing the Tracker API Postman collection

Pivotal Tracker Blog - Mon, 04/06/2015 - 18:40

What is Postman?

Postman is a rest API helper app that is available as a Chrome extension or as a packaged app. Postman lets you build HTTP requests piece by piece, and is particularly interesting to our testing team because it allows you to switch context quickly through the use of “environments.” Postman also has some upgrades that can turn a simple API query into a powerful test that can run in several environments.

Postman

Why use Postman instead of cURL or something else?

We’ve been using Postman on a daily basis on the Tracker test team. We have multiple test environments in various stages of release, and Postman makes comparing responses to the same query in different environments simple and fast. We can also throw in some ad hoc tests with the JetPacks upgrade.

We can organize our requests and easily save variations. You know that go-to text file where you keep all of your cURL examples? Postman is a lot like that file, except you can easily find an example and you don’t have to export variables and cut and paste to the command line. Postman does make it easy for you to translate your request into cURL if you’re more comfortable with the command line, and you can also import that go-to text file to build your own collection.

What is a collection?

A “collection” is simply a group of requests, saved as a JSON file, that you can import and export from Postman. You can also import cURL commands. A collection can be subdivided into folders for more organization, and once you’ve imported a collection, you can access any request in the collection and modify it however you’d like.

What’s in the Tracker v5 API collection?

In a recent Hack Week, the test team decided to deliver a (fairly) complete set of examples for the Tracker v5 API to supplement the examples in our API docs here.

We get quite a few compliments on our API documentation, so we didn’t want to reinvent the wheel. Instead, the examples in the collection are meant to extend the examples in the API docs and illustrate the use of advanced features like filtering, pagination, and other ways to customize your response.

How do I get the Tracker v5 API collection?

The Tracker v5 API collection is in a public repo on GitHub here. The README (hopefully) contains everything you need to know to get started!

Happy posting!

 

The post Introducing the Tracker API Postman collection appeared first on Pivotal Tracker.

Categories: Companies

Excited about CITCON Europe 2015

Thought Nursery - Jeffrey Fredrick - Mon, 04/06/2015 - 16:40

I’m super excited about the upcoming CITCON Europe! As an organizer I’m thrilled with the strong response to the event. It is scheduled in Helsinki for September 11th and 12th and we already have 40 people registered, more than 25% of capacity in just a couple of weeks since we opened registration.

But as an attendee what I’m really excited about right now is who is registered.  When I look at that list of names I picture a lot of familiar faces, and I start to imagine a lot of conversations I’m looking forward to.

Ten years ago PJ sold me on the idea of holding an open space event by comparing it to standard conferences: “You know how the best conversations are the ones that happen in the hallways between sessions? With open space all the sessions are like hallway conversations.” Sounded good to me! And it has been in good in practice now for 25 separate events, on four separate continents. I think we have a case that there’s more than luck involved…

I think an important part of our success has been the selection bias. CITCON is held on a Friday night and Saturday. This makes a big difference in who turns up. This is an event populated by people who have given up personal time to be there. They must have enough interest, enough passion, to make the trek and to put in the time. Details in background — developers, testers, sysadmins, managers, coaches, consultants — matter less than being the kind of person who will make that personal commitment to improvement. And if you’re a person like that, being in room full of others who feel the same way is hugely energizing. I think that’s why these interesting, accomplished people come back again and again, to be part of those conversations.

Now maybe you don’t recognize those names, but you want to be part of that kind of community, what to do then? Easy, join us in Helsinki!

Categories: Blogs

The Power of 3 Words

Agile For All - Bob Hartman - Mon, 04/06/2015 - 16:00

love-in-a-book-agileSome of the most significant messages people deliver to one another often come in just three words. When spoken or conveyed, those statements have the power to forge new friendships, deepen old ones and restore relationships that have cooled.

Yes, this stuff can even have value in corporate work… you’d be amazed at what I’ve seen in terms of organizations and companies that need healing… but it all begins with people, people caring about other people. That, is how powerful services and software begin.

The following three word phrases can enrich every relationship:

I’LL BE THERE – Being there for another person is the greatest gift we can give. When we are truly present for other people, important things happen to them and to us. We are renewed in love and friendship. We are restored emotionally and spiritually. ‘Being there’ is at the very, very core of civility.

I RESPECT YOU – Respect is another way of showing love. Respect conveys the feeling that another person is a true equal. It is a powerful way to affirm the importance of a relationship.

MAYBE YOU’RE RIGHT – This phrase is highly effective in diffusing an argument and restoring frayed emotions. The flip side of “maybe you’re right” is the humility of admitting “maybe I’m wrong.”

PLEASE FORGIVE ME – Many broken relationships could be restored and healed if people would admit their mistakes and ask for forgiveness. All of us are vulnerable to faults, foibles and failures. A man or woman should never be ashamed to own up to he/she has been in the wrong, which is by saying, in other words, that he/she is wiser today than he/she was yesterday.

I THANK YOU – Gratitude is an exquisite form of courtesy. People who enjoy the companionship of good, close friends are those who don’t take daily courtesies for granted. They are quick to thank their friends for their many expressions of kindness. On the other hand, people whose circle of friends is severely constricted often do not have the attitude of gratitude.

COUNT ON ME – “A friend is one who walks in when others walk out.” “Loyalty is an essential ingredient for true friendship; it is the emotional glue that bonds people. Those who are rich in their relationships tend to be steady and true friends. When troubles come, a good friend is there, indicating “you can count on me.”

LET ME HELP – The best of friends see a need and try to fill it. When they spot a hurt they do what they can to heal it. Without being asked, they pitch in and help.

I UNDERSTAND YOU – People become closer and enjoy each other more if they feel the other person accepts and understands them. Letting others know in so many little ways that you understand him or her is one of the most powerful tools for healing your relationship.

GO FOR IT – Some of your friends may be non-conformists, have unique projects and unusual hobbies. Support them in pursuing their interests. Rather than urging your loved ones to conform, encourage their uniqueness – everyone has dreams that no one else has.

I suppose the 3 little words that you were expecting to see have to be reserved for those who are special; that is I LOVE YOU.

The post The Power of 3 Words appeared first on Agile For All.

Categories: Blogs

Knowledge Sharing


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