Skip to content

Feed aggregator

Kanban vs. Scrum, take two

Kanbanery - Wed, 12/07/2016 - 15:55

Artykuł Kanban vs. Scrum, take two pochodzi z serwisu Kanbanery.

Software development is not manufacturing. You can’t take a system designed for building cars and use it to manage software projects. Building a car is a series of identical tasks which don’t change as long as things are going well. There’s one best way to perform each task. Software development is knowledge work. Every step is different, every time. It’s about discovering the best way to do things, and then discovering better ways. It’s creative work, not subject to the rules of manufacturing process management.

Yes. Of course. I agree. But I’m getting really tired of hearing it.

This post is going to be in the form of a rant. Not just because I need it; that would be just selfish. I’m choosing the format of a rant because this needs to be said once and for all in a way that will make an impression.

Because the Kanban Method is not the Toyota Production System. No more than Scrum is rugby.

You never hear anyone saying that software development is not a game. You can’t take a tactic designed for deciding which team gets control of a leather ball and use it to manage software projects. Forcing your way through a concentrated group of blockers is a physical challenge while software development is knowledge work.

I can imagine that the names of two tools frequently applied (often at the same time) to improving value delivery by software companies had similar origins.

Jeff Sutherland and Ken Schwaber, the inventors of Scrum might have been rugby fans, or at least familiar with the sport. Seeing eight people gather every day into a tight circle to work together (the daily standup) might have reminded them of something, like a scrum in rugby. Beyond that, the analogy makes no sense. In rugby, a scrum is used to restart the play after it’s been stopped by an official for some minor infraction of the rules. No one ever says, “we can’t use Scrum in our software team because we aren’t restarting work after someone got in trouble for breaking company policy.” Everyone knows that’s not the kind of scrum we’re talking about.

David Anderson, inventor of the Kanban Method, might have seen that cards in a stack or slots on a board make visible things that are normally invisible, like demand or capacity. Not unlike the way they had to find to make things like capacity in a software development system visible and therefore, manageable. What are those those things called? In Japanese, the word kanban means a visual signal. In Chinese, it means a signpost or a board. So what to call a new tool which incorporates a board full of visual signals?

Kanban-tokens-300x168

Source: Scrum  & Kanban

Or Scrum is related to rugby in the same way that the Kanban Method is related to the Toyota Production System. Both borrowed one word based on a loose association. That’s all.

So indeed, Toyota does use boards on the wall full of visual signals of invisible things that they want to manage. Rugby teams do sometimes put their heads together and work as a group to get something done. But there the similarities end. Can we just leave it at that, please?

Artykuł Kanban vs. Scrum, take two pochodzi z serwisu Kanbanery.

Categories: Companies

CITCON in New York City

Paul Julius - Sat, 11/26/2016 - 21:14

I am very excited that we will be hosting CITCON in New York City on December 9 & 10, 2016.

Registrations are still open: http://citconf.com/newyork2016/

I am proud that my company, Intent Media https://intentmedia.com/, has signed on as the Venue Sponsor. As Chief Technology Officer, I am excited to showcase some of the great things we have been doing at Intent like

* mob programming
* serverless architectures
* employee growth based management
* continuous delivery
* polyglot programming

Should be tons of fun! Join us!

Categories: Blogs

Scaling simplicity – Cascading control and permission management in Kanbanery

Kanbanery - Wed, 11/23/2016 - 17:44

Artykuł Scaling simplicity – Cascading control and permission management in Kanbanery pochodzi z serwisu Kanbanery.

Merging complexity and ease of use is always challenging. At Kanbanery, our aim has always been to create a product that is easy to use, and yet can scale with our clients’ businesses. In the early days, many of our clients were startups, and we know that startups aspire to greatness and some will achieve it. They need an agile project management tool that doesn’t get in the way of a small team building a great minimal viable product. When they become successful, they shouldn’t have to change their toolkit for some ungainly enterprise tool that requires a full-time administrator just to manage accounts, permissions, and workflows. One of the primary tools that we used to achieve flexibility was Principle-driven Design, which I described in an earlier blog post. A startup that chooses Kanbanery because they share our principles of transparency and collaborative learning will grow to become an enterprise that continues to share those principles.

An illustration is our permission management system.

At one time in a past life, I was a Jira system administrator for a large IT company. We had dozens of teams supporting or building dozens of products, each with different workflows. We had layers of management and stakeholders in various departments who had roles to play in multiple projects. The result was many groups with hundreds of overlapping permissions and every day I was adding and removing people from groups, defining new groups (never removing them), adding (but never removing) group permissions, and adding (never removing) workflows. Some companies think they need that level of control, but I didn’t want to do that to any of Kanbanery’s clients.

I knew that plenty of large companies use physical kanban boards. You can’t hide a physical board from someone who has a key to the room. You can’t show anyone some columns but not others. You can’t control who can move tasks or in which direction. And yet it works. That’s because people are basically good and most are pretty smart (they call it knowledge work for a reason), and when you trust them, their natural inclination is not to let you down.

So When we designed the Kanbanery permission system, we kept it simple. There are three roles: viewer, team member, and manager. A viewer can see anything, including comments, attachments, and reports. They see all the same things that a member of the team would see when they look at a board, but they can’t move task cards, create task cards, or change anything on the board. The physical analog is looking at a task board through a window. They see the same things the team sees. No secrets. That’s how we build trust.

A team member can add and move cards around and add comments and attachments to a card. They can also edit anything on a card.

Adding a team member in Kanbanery

A board manager (there can be several) can do everything a team member can and they can also change the board layout and settings and manage board users.

Personally, I use only the board manager role, giving all the control to everyone on my teams. No one has ever made a mistake or abused their power. People don’t have to ask me to add them to a board or to change a board’s settings or layout since anyone on the team can do all that by themselves. I had enough of that back when I was a Jira admin.

At the higher level, we have account and workspace management. The one thing that I do feel pretty strongly about controlling is my clients’ costs. The person who creates a company account and pays for it is the only person who can change the plan level, upgrade to the Pro plan, or add team members over the plan limit. The person who pays the bill, or who entered the company credit card should never be surprised by an invoice. So when someone creates an account, paid or not, they own it. In the account is one workspace. If they have a pro plan, then can create more workspaces.

Workspaces can be handy when you need to control access by product, team, department, or client. A workspace can have many managers, assigned by the account owner. These managers can do anything within a workspace that the account owner can, except things that would cost more money. They can create and delete boards and manage those boards and all their members.

It sounds complex, but after hundreds of thousands of clients using Kanbanery over almost ten years, I can only remember four times that we got a support request to clarify how something works.

Because from the standpoint of a person adopting Kanbanery for their company, the workflow is natural. They create an account, then perhaps they rename the workspace or create a few workspaces. They automatically are the workspace owners for all workspaces in their account. Perhaps later they want someone to help, and then they just add that person as an additional workspace manager. The account owner or their workspace managers then create new Kanbanery boards, and they are automatically managers of those boards. Again, if they want someone else to manage a project board, they just make them a board manager.

Only twice in Kanbanery’s history has this caused a problem. Both times it was because an engineer or project manager created an account for their team and paid with a company credit card borrowed for the purpose. In both cases, other teams in the company saw Kanbanery and liked it, and Kanbanery use grew from the original team to other departments. Later, the people who created the accounts left the companies and we’d start getting requests from accounting for invoices, or we were asked to update the credit card on file. So we’d migrate the account ownership to someone higher in the organization or in accounting and the problem was solved.

A student who created a free Kanbanery account for managing their coursework can assume it’s as easy to use as Trello because they never have to see the power that’s under the hood until they need it. A large corporation using Kanbanery in multiple departments for sales, marketing, legal, recruitment, and of course product development just sees a simple tool that scales intuitively. So by giving account owners total power over everything in the account and the ability to easily share that power, we have a simple system of automatically cascading responsibility that just works, because it’s based on maximizing simplicity and assuming trust and transparency.

Artykuł Scaling simplicity – Cascading control and permission management in Kanbanery pochodzi z serwisu Kanbanery.

Categories: Companies

A Whirlwind Tour of the Kotlin Type Hierarchy

Mistaeks I Hav Made - Nat Pryce - Fri, 10/28/2016 - 10:08
Kotlin has plenty of good language documentation and tutorials. But I’ve not found an article that describes in one place how Kotlin’s type hierarchy fits together. That’s a shame, because I find it to be really neat1. Kotlin’s type hierarchy has very few rules to learn. Those rules combine together consistently and predictably. Thanks to those rules, Kotlin can provide useful, user extensible language features – null safety, polymorphism, and unreachable code analysis – without resorting to special cases and ad-hoc checks in the compiler and IDE. Starting from the Top All types of Kotlin object are organised into a hierarchy of subtype/supertype relationships. At the “top” of that hierarchy is the abstract class Any. For example, the types String and Int are both subtypes of Any. Any is the equivalent of Java’s Object class. Unlike Java, Kotlin does not draw a distinction between “primitive” types, that are intrinsic to the language, and user-defined types. They are all part of the same type hierarchy. If you define a class that is not explicitly derived from another class, the class will be an immediate subtype of Any. class Fruit(val ripeness: Double) If you do specify a base class for a user-defined class, the base class will be the immediate supertype of the new class, but the ultimate ancestor of the class will be the type Any. abstract class Fruit(val ripeness: Double) class Banana(ripeness: Double, val bendiness: Double): Fruit(ripeness) class Peach(ripeness: Double, val fuzziness: Double): Fruit(ripeness) If your class implements one or more interfaces, it will have multiple immediate supertypes, with Any as the ultimate ancestor. interface ICanGoInASalad interface ICanBeSunDried class Tomato(ripeness: Double): Fruit(ripeness), ICanGoInASalad, ICanBeSunDried The Kotlin type checker enforces subtype/supertype relationships. For example, you can store a subtype into a supertype variable: var f: Fruit = Banana(bendiness=0.5) f = Peach(fuzziness=0.8) But you cannot store a supertype value into a subtype variable: val b = Banana(bendiness=0.5) val f: Fruit = b val b2: Banana = f // Error: Type mismatch: inferred type is Fruit but Banana was expected Nullable Types Unlike Java, Kotlin distinguishes between “non-null” and “nullable” types. The types we’ve seen so far are all “non-null”. Kotlin does not allow null to be used as a value of these types. You’re guaranteed that dereferencing a reference to a value of a “non-null” type will never throw a NullPointerException. The type checker rejects code that tries to use null or a nullable type where a non-null type is expected. For example: var s : String = null // Error: Null can not be a value of a non-null type String If you want a value to maybe be null, you need to use the nullable equivalent of the value type, denoted by the suffix ‘?’. For example, the type String? is the nullable equivalent String, and so allows all String values plus null. var s : String? = null s = "foo" s = null s = bar The type checker ensures that you never use a nullable value without having first tested that it is not null. Kotlin provides operators to make working with nullable types more convenient. See the Null Safety section of the Kotlin language reference for examples. When non-null types are related by subtyping, their nullable equivalents are also related in the same way. For example, because String is a subtype of Any, String? is a subtype of Any?, and because Banana is a subtype of Fruit, Banana? is a subtype of Fruit?. Just as Any is the root of the non-null type hierarchy, Any? is the root of the nullable type hierarchy. Because Any? is the supertype of Any, Any? is the very top of Kotlin’s type hierarchy. A non-null type is a subtype of its nullable equivalent. For example, String, as well as being a subtype of Any, is also a subtype of String?. This is why you can store a non-null String value into a nullable String? variable, but you cannot store a nullable String? value into a non-null String variable. Kotlin’s null safety is not enforced by special rules, but is an outcome of the same subtype/supertype rules that apply between non-null types. This applies to user-defined type hierarchies as well. Unit Kotlin is an expression oriented language. All control flow statements (apart from variable assignment, unusually) are expressions. Kotlin does not have void functions, like Java and C. Functions always return a value. Functions that don’t actually calculate anything – being called for their side effect, for example – return Unit, a type that has a single value, also called Unit. Most of the time you don’t need to explicitly specify Unit as a return type or return Unit from functions. If you write a function with a block body and do not specify the result type, the compiler will treat it as a Unit function. Otherwise the compiler will infer it. fun example() { println("block body and no explicit return type, so returns Unit") } val u: Unit = example() There’s nothing special about Unit. Like any other type, it’s a subtype of Any. It can be made nullable, so is a subtype of Unit?, which is a subtype of Any?. The type Unit? is a strange little edge case, a result of the consistency of Kotlin’s type system. It has only two members: the Unit value and null. I’ve never found a need to use it explicitly, but the fact that there is no special case for “void” in the type system makes it much easier to treat all kinds of functions generically. Nothing At the very bottom of the Kotlin type hierarchy is the type Nothing. As its name suggests, Nothing is a type that has no instances. An expression of type Nothing does not result in a value. Note the distinction between Unit and Nothing. Evaluation of an expression type Unit results in the singleton value Unit. Evaluation of an expression of type Nothing never returns at all. This means that any code following an expression of type Nothing is unreachable. The compiler and IDE will warn you about such unreachable code. What kinds of expression evaluate to Nothing? Those that perform control flow. For example, the throw keyword interrupts the calculation of an expression and throws an exception out of the enclosing function. A throw is therefore an expression of type Nothing. By having Nothing as a subtype of every other type, the type system allows any expression in the program to actually fail to calculate a value. This models real world eventualities, such as the JVM running out of memory while calculating an expression, or someone pulling out the computer’s power plug. It also means that we can throw exceptions from within any expression. fun formatCell(value: Double): String = if (value.isNaN()) throw IllegalArgumentException("$value is not a number") else value.toString() It may come as a surprise to learn that the return statement has the type Nothing. Return is a control flow statement that immediately returns a value from the enclosing function, interrupting the evaluation of any expression of which it is a part. fun formatCellRounded(value: Double): String = val rounded: Long = if (value.isNaN()) return "#ERROR" else Math.round(value) rounded.toString() A function that enters an infinite loop or kills the current process has a result type of Nothing. For example, the Kotlin standard library declares the exitProcess function as: fun exitProcess(status: Int): Nothing If you write your own function that returns Nothing, the compiler will check for unreachable code after a call to your function just as it does with built-in control flow statements. inline fun forever(action: ()->Unit): Nothing { while(true) action() } fun example() { forever { println("doing...") } println("done") // Warning: Unreachable code } Like null safety, unreachable code analysis is not implemented by ad-hoc, special-case checks in the IDE and compiler, as it has to be in Java. It’s a function of the type system. Nullable Nothing? Nothing, like any other type, can be made nullable, giving the type Nothing?. Nothing? can only contain one value: null. In fact, Nothing? is the type of null. Nothing? is the ultimate subtype of all nullable types, which lets the value null be used as a value of any nullable type. Conclusion When you consider it all at once, Kotlin’s entire type hierarchy can feel quite complicated. But never fear! I hope this article has demonstrated that Kotlin has a simple and consistent type system. There are few rules to learn: a hierarchy of supertype/subtype relationships with Any? at the top and Nothing at the bottom, and subtype relationships between non-null and nullable types. That’s it. There are no special cases. Useful language features like null safety, object-oriented polymorphism, and unreachable code analysis all result from these simple, predictable rules. Thanks to this consistency, Kotlin’s type checker is a powerful tool that helps you write concise, correct programs. “Neat” meaning “done with or demonstrating skill or efficiency”, rather than the Kevin Costner backstage at a Madonna show sense of the word↩
Categories: Blogs

We’re Moving: Rally Blog Has a New Home on CA Highlight

Rally Agile Blog - Thu, 10/06/2016 - 17:24

You’ve probably heard by now that Rally Software has become part of the CA Technologies family. As a result we’re moving the agile blogs you know and love from here, to there: http://blogs.ca.com/tag/agile-management/.

Beginning in mid-October, the Rally blogs will no longer be available in their current locations.

We’ve already moved our most popular blog posts over to the CA Highlight blog. You'll find the same great agile management topics and content written by your favorite bloggers, with added links to interesting, related content. The technical (engineering, development, DevOps) blogs will live at CA Highlight as well.

So set a new bookmark to the CA Highlight blog or subscribe using the link at the bottom of the page. Then, browse the Agile Management and Technical Innovation categories to see posts you may have missed, and check out authors new to you from the CA family. See you there!

Rally
Categories: Companies

Integreer Kwaliteit met Lean Software Ontwikkeling

Ben Linders - Wed, 08/24/2016 - 13:26

Integreer kwaliteit Agile LeanAgile methoden zoals Scrum leggen de nadruk op functionaliteit. Klanten verwachten echter naast functionaliteit dat ook de kwaliteit van het product in orde is. Waar Agile voornamelijk aandacht geeft aan het software team en de interactie met de omgeving, kijkt Lean naar de gehele keten: van klantbehoefte tot waarde voor de klant. Een van de aspecten van Lean Software Ontwikkeling is het integreren van kwaliteit.

Lean Software Ontwikkeling combineert Agile en Lean met de volgende 7 principes:

  1. Verminder Verspillingen (Eliminate Waste)
  2. Integreer Kwaliteit (Build Quality In)
  3. Leer Voortdurend (Learn Constantly)
  4. Lever Snel (Deliver Fast)
  5. Betrek Iedereen (Engage Everyone)
  6. Verbeter Continue (Keep getting Better)
  7. Optimaliseer het Geheel (Optimize the whole)
Kwaliteit begint bij de klanten


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Mijn definitie van kwaliteit (zie Hoe zorg je met Scrum voor Kwaliteitsproducten en Diensten) is:

Kwaliteit is de mate waarin voldaan wordt aan de behoeften van de gebruikers, en aan de eisen van de opdrachtgevers. Dat kunnen zowel functionele behoeften zijn (iets wat het product of dienst moet doen), of “performance”of niet-functionele eisen (hoe snel, hoe veel, de betrouwbaarheid, etc), vaak is het een combinatie van beide.

Het zijn je klanten die bepalen wat kwaliteit is (en wat niet), en wat vereist is voor een goede kwaliteit. Pas als je weet wat je klanten nodig hebben kun je naar goed oplossingen zoeken om aan hun wensen te voldoen. Je integreert daarmee kwaliteit in het gehele ontwikkelproces. Het juiste product

Hoe kom je erachter wat de klant nodig heeft? Agile kent diverse practices waarin het team en de klanten (in de Scrum praat men over product owner ipv klant) intensief samenwerken om ervoor te zorgen dat het juiste product geleverd wordt. Voorbeelden daarvan zijn de planning game en de product demonstratie.

In de planning game gaat het erom dat de product eisen duidelijker worden. Wat willen klanten bereiken met het product, welke waarde moet het hun gaan bieden? Wat moet het product doen om die waarde te kunnen leveren? Maar ook de kwaliteitseisen: hoe snel moet het werken, en hoe betrouwbaar en stabiel moet het zijn? Het team benut zijn kennis en ervaring om te bepalen wat mogelijk is, en hoe het product op een Lean manier ontwikkelt kan worden.

In de product demonstratie laat je het product zien aan de klanten en vraag om je feedback. Is dit wat de klant wil? Is het goed genoeg? Maar ook: Is het snel genoeg, handig te gebruiken. Betrouwbaar en veilig? En, gegeven wat het product nu doet, wat is er nog meer nodig? Kwaliteit met Agile en Lean

Hoe gaat dat in de praktijk? Laten we kijken naar een medisch systeem wat specialisten gebruiken om onderzoek te doen met patiënten. De specialisten (klanten) willen een aantal mogelijkheden hebben om data en scans van een patiënt te bekijken. Ze willen beelden van eerdere scans kunnen oproepen, inzoomen, en vergelijken. Omdat ze dat vaak met de patiënt erbij doen moet dat snel gaan, en eenvoudig te bedienen zijn. De gegevens mogen niet fout zijn, de specialisten gebruiken ze om beslissingen te nemen waar het leven van de patiënt van af kan hangen.

In de discussies vooraf en in de planning game formuleren de product owner en het team de acceptatie criteria. Voor kwaliteitseisen moeten die criteria meetbaar zijn. Dus niet “snel genoeg” maar “in 90% van de gevallen reageert het systeem binnen 1 seconde”.

Samen met de product owner formuleren de teamleden user stories. De acceptatiecriteria in de user stories worden door het team gebruikt om af te spreken hoe ze de software gaan maken en verifiëren.

Bijvoorbeeld, voor een bepaalde user story doen ze een spike, ze maken een stukje sofware en een testcase die meet hoe snel de software is om te bepalen of wat de klant wil haalbaar is. Voor een andere user story wil het team pair programming gebruiken, het is een complexe functie waarmee de team leden nog geen ervaring hebben.

Er zijn ook stories waarbij test driven design volgens het team de beste aanpak is, en een enkele story waarbij de klant nog niet echt weet wat het product precies moet gaan doen om er op  een handige manier mee te kunnen werken, daar lijkt prototyping met Lean Startup het beste te passen.

De vereiste functionaliteit en kwaliteit is bepalend voor de aanpak. De product owner maakt duidelijk wat er nodig is en welke kwaliteit de klanten verwachten. Het team weet wat met een bepaalde manier van werken haalbaar is, en check in de planning game met de product owner. Te weinig kwaliteit is niet goed, maar teveel ook niet. Het gaat bij lean om het vinden van de juiste balans tussen tijd, geld en kwaliteit voor het leveren van functionaliteit.

In de demonstratie wordt de software getoond en gechecked of het voldoet. Daarbij telt zowel de functionaliteit als de kwaliteit. Het moet niet alleen werken, het moet ook snel genoeg zijn, betrouwbaar, bedienbaar, etc. Pas dan voldoet het product aan alle eisen en is het af.

De kracht zit in de samenwerking tussen het team en de product owner gedurende de ontwikkeling. Is er een gedeeld beeld wanneer, hoe en waarvoor klanten het product gebruiken? Wat betekent het product voor hun en welke waarde het kan toevoegen? Kan de product owner voldoende duidelijk maken wat nodig is, en checken de teamleden of ze het goed begrepen hebben? Leren ze van dingen die niet goed zijn gegaan? Integreer kwaliteit

Lean en Agile versterken elkaar als het gaat om de kwaliteit van de producten en diensten. Met agile en lean practices integreer je kwaliteit in de volledige productontwikkelingsketen.

kwaliteitsverbeteringIn de workshop software kwaliteitsverbetering leer je hoe je goede producten en diensten kunt leveren. Kwaliteitsverbetering helpt organisaties om beter te voldoen aan de behoeften van de gebruikers en aan de eisen van de opdrachtgevers.

Categories: Blogs

Continue Verbetering met Agile in Bits&Chips

Ben Linders - Wed, 08/24/2016 - 11:05

bitchipslogoMijn artikel Continue Verbetering met Agile is gepubliceerd in Bits&Chips nr 4. In dit artikel laat ik zien dat continue verbetering een integraal onderdeel is van de Agile-mindset en van de Agile-principes en -practices, en geef ik tips en advies voor verbeteren met agile:

Silver bullets bestaan niet in softwareontwikkeling. Effectieve softwareteams bepalen zelf hoe ze hun werk doen, passen zich continu aan en verbeteren zichzelf. Continue verbetering is ingebed in de Agile-mindset en -principes en helpt zo om de flexibiliteit in bedrijven te verhogen en meer waarde te leveren, betoogt Ben Linders.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Bits&Chips publiceert een magazine over ontwikkelingen in de high-tech industrie en organiseert de jaarlijkse smart systems conferenties (Software-Centric Systems Conference in 2016).

Eerder dit jaar publiceerde Bits&Chips een Engelstalige editie, met daarin mijn artikel Delivering quality software with Agile.

Categories: Blogs

Survey on Agile Manifesto 2.0

Ben Linders - Mon, 08/15/2016 - 17:59

Survey agile manifesto KamleshIs There a Need For Agile Manifesto 2.0? That’s the question that Kamlesh Ravlani, Agile / Lean Coach and Scrum Trainer, is asking the Agile community. He is running a Survey on Agile Manifesto 2.0, which he announced on LinkedIn Pulse.

Lately there is a lot of buzz in the Agile community around the need to update the Agile Manifesto. Many agilists have been vocal about it and some have floated their own versions of the manifesto. Let’s explore collectively as a community the need for changes in the Agile Manifesto.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Please support this survey by answering three questions (it only takes a couple of minutes).

Kamlesh will publicly share the findings from the survey:

Who can participate?
All practitioners, Agile coaches, trainers and thought leaders are invited to share their opinion.

How will this information be used?
I intend to share the results of this survey with community via recognized platform for example – Infoq, ScrumAlliance, etc.

I’ve responded to this survey and I’m hoping many of you will do the same :-).

Categories: Blogs

Reply to Comments with @ Mentions

Pivotal Tracker Blog - Wed, 08/10/2016 - 18:39

Last month, we made it so that clicking on a story comment notification (either in the app or in email) took you directly to the comment in which you’d been mentioned.

“That’s great and all,” we hear you saying, “but replying to that comment can be a bit painful when you’re trying to keep everyone already @ mentioned in the conversation.”
Fair point!

Hold onto your horses, because now you can quickly reply to everyone who’s part of a comment thread with one click.

Just mouse over a comment and click the new Reply button.

Screen Shot 2016-08-10 at 9.37.26 AM

You’ll notice that the people previously mentioned are selected by default, making it easy to remove them if you meant to reply only to the comment author. To keep them, just hit the right arrow key and start typing to your heart’s content.

As always, please share your feedback via the in-app widget (in the Help dropdown when in a project), or email us.

The post Reply to Comments with @ Mentions appeared first on Pivotal Tracker.

Categories: Companies

Feedback in Agile

Ben Linders - Wed, 08/10/2016 - 11:38

feedback agileAgile software ontwikkeling kent ingebouwde feedback. Iedere iteratie wordt afgesloten met een sprint review/demo en een agile retrospective, waarin feedback centraal staat. Ook tijdens de iteratie is er gelegenheid voor feedback. Een overzicht van de diverse manieren van feedback in agile en de voordelen die feedback oplevert. Product Demonstratie

De product demonstratie (sprint review in Scrum) is bedoeld om feedback te krijgen op het product. Een goede demo zorgt voor antwoorden op vragen zoals:

  • Doet het product wat het zou moeten doen?
  • Is het product bruikbaar?
  • Welke functionaliteit is verder nodig?
  • Wat kan er aan het product verbeterd worden?
Agile Retrospective


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

In de agile retrospective reflecteert het team op hun proces. In de retrospective geven teamleden feedback naar elkaar. Deze feedback geeft inzicht in de manier van werken en helpt om continu te verbeteren.

Een goede retrospective geeft inzicht in:

  • Wat ging er goed en wat heb je als team geleerd?
  • Welke problemen zijn er geweest, wat zou je willen veranderen?
  • Welke sterktes en kwaliteiten heeft het team?
  • Hoe kan het team zich verder ontwikkelen?

Cover Waardevolle Agile Retrospectives ManagementboekWaardevolle Agile Retrospectives is het 1e Nederlandstalige Agile boek voor het faciliteren van retrospectives. Met vele oefeningen, het “wat” en “waarom” van retrospectives, de business value en de voordelen die retrospectives brengen. Tevens practische tips en adviezen voor het introduceren en verbeteren van retrospectives. Aanbevolen voor agile coaches, Scrum masters, project managers, product managers en facilitators die al enige ervaring hebben met retrospectives. Andere feedback momenten

De demo en retrospective zijn de bekendste feedback momenten in Agile. Maar er zijn er nog meer. Tijdens de dagelijkse stand up kunnen team leden elkaar feedback geven. Bijvoorbeeld over hoe ze de samenwerking in het team ervaren en hoe een activiteit gegaan is. In de planning game geeft het team feedback op de user stories naar de product owner, samen stemmen ze de inhoud van de iteratie af. Wat levert feedback op

Feedback in agile helpt om te leren en continu te verbeteren. De voordelen die feedback in agile oplevert zijn:

  • Met frequente snelle feedback kun je eenvoudiger bijsturen
  • Concrete feedback die kort na een gebeurtenis gegeven wordt, maakt eenvoudiger om actie te ondernemen
  • Verbeteren in kleine stapjes is eenvoudiger, snelle feedback maakt het mogelijk.
  • Goede feedback verbeterd de relatie tussen mensen en helpt om effectiever samen te werken

Agile wordt je door agile te doen. Wil je met agile resultaten bereiken dan is goede feedback essentieel. De sprint review/demo en de agile retrospective zorgen voor continue product- en procesverbetering, waardoor teams efficiënt en effectief producten kunnen leveren.

Categories: Blogs

Gratis mini-workshop over Agile Retrospectives

Ben Linders - Wed, 08/10/2016 - 11:06

AgileHubNoordOp 21 september geef ik een gratis mini-workshop over agile retrospectives in Groningen. In deze mini-workshop gebruik ik oefeningen uit mijn succesvolle workshop Waardevolle Agile Retrospectives.

Retrospectives helpen je om agile effectief toe te passen continu te verbeteren. Je pakt ermee problemen aan en zorgt voor een goede werksfeer in je teams. Scrum masters en Agile coaches halen  meer uit teams met behulp van een toolbox met retrospective oefeningen.

In deze mini-workshop geeft Ben Linders, auteur van het boek Waardevolle Agile Retrospectives, een introductie van de “waarom” en “wat” van retrospectives. Je oefent verschillende manieren om retrospectives te doen en krijgt tips en adviezen voor het introduceren en verbeteren van retrospectives.

Deze mini-workshop wordt gegeven in samenwerking met AgileHubNoord, een onafhankelijke netwerkorganisatie die als doel heeft om Agile-professionals uit Noord-Nederland met elkaar te verbinden, kennis met elkaar te delen en om het Agile-gedachtegoed onder de aandacht te brengen.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Er zijn helaas geen plaatsen meer beschikbaar voor deze workshop (hij was in enkele dagen volledig “uitverkocht”), maar er is een wachtlijst. Als mensen zich afmelden word je automatisch aangemeld voor de meetup.

De workshop workshop Waardevolle Agile Retrospectives geef ik zowel via open inschrijving als in-house, aangepast aan de specifieke wensen van jou bedrijf en situatie. Neem contact met mij op!

Categories: Blogs

Chapter on Visual Management added to What Drives Quality

Ben Linders - Wed, 08/10/2016 - 09:30

What Drive Quality coverA new chapter which explores how visual management can be used to improve quality of software products has been added to my second book What Drives Quality.

One of the principles from agile and lean software development is transparency. Making things visible helps teams to decide what to develop and to collaborate effectively with their stakeholders. It can also help to increase the quality of software. You can apply visual management to make potential quality issues visible early and prioritize solving them. The examples that I provide explain clearly why quality matters and how visualization can be used to establish, maintain and even increase the quality of software products.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

What drives quality provides insight into the factors that drive the quality software products and services. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.

The book What Drives Quality is available for a reduced price on Leanpub as long as it’s under development. If you buy the book now you will automatically get all chapters that are added in the future for free. So don’t wait too long, get your copy now!

Categories: Blogs

Why do you want to become agile?

Ben Linders - Mon, 08/08/2016 - 13:16

Why becoming agileBecoming agile can help to achieve organizational goals. But setting agile as a goal for an organization does not work. The goal for a software organization should be to achieve results by delivering valuable products and services, not to become agile. Hence my question: do you know why do you want to become agile?
Yes, seriously, why would you do agile? There are lot’s of good reasons (and also some less good ones), but what’s your reason to become agile? What do you expect from agile?

Agile transformations seriously impact organizations (they should!). It’s a reorganization of people, work, and authorities. Employees are asked to think about the way they want to do their work, and to take responsibility. Managers have to give room to their employees. There must be a good reason to do all of this. You should know the reason why you want to become agile, and let everyone involved know.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

It is important to know why you want to increase the agility of your organization and what you expect to achieve with agile. To know why would you want to work in an agile way, why you want your culture to become agile.

Again, agile is not an goal or state that needs to be reached. It’s important that every manager and employee knows why the organization starts an agile journey and what is expected from agile. Reasons to become agile

If I ask people in organizations that I work with why they want to become agile they often look surprised at first. Of course they want agile! Everybody is doing agile, so it must be good. Agile is supposed to make them faster, cheaper and better. So let’s do it. If it only was that easy … every organization should be truly agile by now.

Does knowing the reason matter? Yes, it does! If you know the reason why you want to become agile, chances of success increase significantly. If people know why they have to chance, if they see the purpose, they are more willing to do it.

Some of the reasons that I have heard in organizations on why they want to become agile are:

  • Deliver the right products and services
  • Be able to deliver faster
  • Increase customer satisfaction and win new customers
  • Create innovative products with motivated employees
  • Reduce the cost of development and management
  • Improve the quality of goods and services
  • Effective cooperation between development and management
  • (your reason here)

My advice to companies is to think about why they want to become agile. Pick one reason, and one only. State very clearly in one sentence what your main objective to become agile. What would make your agile transformation successful. Going for one goal is hard enough. Also, the reason you choose impacts the way that agile will be applied (it should!), so choose your reason carefully. What is your goal with agile?

Do you want to deliver products with good quality? Or be able to better meet the needs of your customers? Lower your costs? Increase the motivation of your employees? Whatever your reason is to become agile, contact me, and I’ll help you to get results :-).

Categories: Blogs

Books by Ben Linders on Leanpub

Ben Linders - Mon, 08/08/2016 - 11:07

Books Ben Linders LeanpubAll of the books that I have published on Leanpub are now available in a bundle: Books by Ben Linders. You get a 30% discount when you buy my books with this bundle.

Currently this bundle contains three books:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.

My book What Drives Quality helps you to prevent software problems from happening by building an shared understanding what drives software quality. It enables you to effectively take actions, saving time and money!

My book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.

My 2nd and 3rd book are being written incrementally. Currently they are only sold via Leanpub. When you buy the book on Leanpub you will automatically receive new chapters when they become available, free of charge.

All books that I will publish in the future on leanpub will be added to this bundle.

Categories: Blogs

Masterclasses at Agile Tour Kaunas

Ben Linders - Mon, 08/01/2016 - 18:49

agiletour2016kaunas I’m giving two masterclasses at Agile Tour Kaunas on October 11 and 12 on Retrospectives and on Agile and Lean. Tickets for these agile workshops can be bought on the Agile Tour Lithuania courses webpage.

The two masterclasses are:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

This is the first time that I’m giving my workshops in Lithuania. I’m grateful to Agile Lithuania for inviting me to their country.

The early bird price (till September 1st) for my masterclasses is 319 Eur (VAT not applicable). Regular price: is 379 Eur.

As an adviser, coach and trainer I helps organizations by deploying effective software development and management practices. I provide workshops and training sessions, public and private sessions. Here’s a list of my upcoming public sessions.

Categories: Blogs

A Summary of More Fearless Change in 15 Tweets

Ben Linders - Fri, 07/29/2016 - 11:58

More Fearless Change book coverThe book More Fearless Change by Mary Lynn Manns and Linda Rising provides ideas for driving change in organizations, using the format of patterns. This book is an new and extended version of their successful book Fearless Change.

I did an interview with Mary Lynn and Linda about how people are viewing change in organizations, the purpose of patterns and the benefits that organizations can get from using them, the new patterns that are described in More Fearless Change and the insights were added to the existing patterns, and their expectations about what the future will bring us in organizational change. You can read it on InfoQ: Q&A on the Book More Fearless Change. 15 Quotes from More Fearless Change


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Here’s a set of 15 quotes from the new patterns that have been added in More Fearless Change. I’m tweeting these quotes with #fearlesschange: No matter how great your new idea is and how well prepared you are, you are bound to meet some level of resistance Inspire people throughout the change initiative with a sense of optimism rather than fear When you feel discouraged, look for the bright spots among the challenges that surround you Displaying a warm smile and a willingness to be nice even when negativity surrounds you can go a long way To make progress toward your goal, state precisely what you will do as you take the next baby step To encourage adoption of a new idea, experiment with removing obstacles that might be standing in the way Change the environment in a way that will encourage people to adopt the new idea When you have a chance to introduce someone to your idea, you don’t want to stumble around for the right words to say Persuasion tactics must consider what people are logically thinking as well as what they are feeling By focusing on the future, individuals may be more motivated to let go of the past Your change initiative is a series of baby steps As you prepare to move forward, occasionally look for a quick and easy win that will have visible impact Stay in touch with your supporters—never assume that news of your progress is known across the organization Rumors need to be debunked before they take root and create significant concerns and anxieties during the change You can’t spend time and energy addressing every bit of resistance you meet Patterns can help you to drive change

If you want to truly change organizations, don’t try to plan it up front and don’t look for recipes. That won’t work (literally!). Patterns provide a useful format to convey ideas and to apply those ideas in a specific situation to do sustainable change.

Mary Lynn Manns and Linda Rising did a great job in this updated and extended version of Fearless Change. The experiences that they added to the existing patterns help you to get a deeper understanding, and the new patterns that they describe in this book are very valuable.

The patterns described in More Fearless Change help you to recognize situations and to come up with solutions for dealing with them. If you are dealing with change in organizations (and who isn’t nowadays) then I highly recommend to read this book and keep it close to you, as it will be useful at many times!

Categories: Blogs

Books with Agile Practices and Tips

Ben Linders - Thu, 07/28/2016 - 09:54

Agile Practices and Tips Books BundleA new bundle of books with agile practices and tips has been released on Leanpub. Buy these books with a 40% discount!

The bundle includes six great books from eleven authors, helping you to make your agile journey easier to travel, more successful, and fun!

  • With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.
  • A Toolbox for the Agile Coach:  96 Visualization Examples showing how great teams visualize their work.
  • The tools and techniques provided in the Forming Agile Teams workbook offer an alternative-proven way to add more structure, transparency and visibility to the work that you do when Forming Agile Teams, by combining visual explanations with techniques and tips to support Scrum Masters crucial role within the organization.
  • The Scrum Master Workbook Part 1 provides 15 weeks of accelerated learning. It teaches you ways to deal with conflict, bugs, interruptions, meetings and many more topics.
  • Patterns of Agile Journeys shares stories and patterns to help you recognize situations you may find yourself in on your own journey. Use the tips in this book to reinforce or counteract the patterns you see.
  • The book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Together these books provide many useful tips and practices for your agile journey. Buy them for $40,77 (regular price is $67,95).

There’s also the Agile Retrospectives Books Bundle with six great books that will make your agile retrospectives rock, and the Valuable Agile Retrospectives – All Languages Bundle which contains all language editions of my successful book Getting Value out of Agile Retrospectives.

Categories: Blogs

How to Rescue Yourself From a Risky Setback

Pivotal Tracker Blog - Wed, 07/27/2016 - 16:52

Did you ever take a risk and then realize, “OMG, I am in too deep?”

But by the time you realized it, it was too late.

There was no time for a do-over.

You were stuck and really the only logical thing to do next was to throw in the towel and call it quits.

Or was it?

Well, in today’s episode of FemgineerTV, we’re going to tackle the topic of how you can rescue yourself from a risky setback.

And to help us out, I’ve invited Jessica Mah, the CEO and Co-Founder of InDinero. She has grown InDinero from zero to multimillion dollar revenues with nearly 200 full-time staff, and has been on the cover of Inc. Magazine, and featured in the Forbes and Inc. 30 Under 30 lists. Jessica studied computer science at UC Berkeley.

Jessica went from engineering to entrepreneurship right out of college, but it hasn’t exactly been a bed of roses for her.

She’s had to overcome a number of setbacks along the way, including being on the brink of bankruptcy!

She’s been kind enough to share her story openly with us, and as you watch the episode you’ll learn:

    • Why it’s important to set goals (but not too many!)
    • How to respond to those
    • Why being direct with teammates and customers can help you work through a risky setback
    • How partners can be helpful, and how to nurture those relationships to withstand setbacks
    • How you can feel fearless and confident, but how it’s like a gas tank and needs to be replenished

If you’ve agonized over a significant setback, then I highly recommend watching this episode!

Listen to the episode on iTunes!

You can listen to this episode of FemgineerTV on iTunes. Please take a moment to leave us a review. Your positive review will help us get featured in News & Noteworthy and bring more exposure to the work we’re doing, as well as the talented guests we feature!


FemgineerTV is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

The post How to Rescue Yourself From a Risky Setback appeared first on Pivotal Tracker.

Categories: Companies

Manifesto voor Agile Veranderen

Ben Linders - Tue, 07/26/2016 - 10:47

Manifesto Agile Veranderen Ben LindersHet manifesto voor agile veranderen helpt organisaties om hun agility te verhogen. Het zorgt voor blijvende verbetering van de resultaten, tevreden klanten, en blije medewerkers. Dit eerste artikel over Agile Veranderen beschijft de uitgangspunten en waarden met behulp van het manifesto voor agile veranderen.

Agile software ontwikkeling is gebaseerd op het Manifesto voor Agile Software Ontwikkeling. Dit manifesto bevat vier waarden en twaalf principes. Het manifesto voor agile veranderen is op een zelfde manier opgebouwd. Het beschrijft mijn visie en werkwijze in organisatieverandering, samengevat in vier waarden. Mijn verander “waarden”


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Dit zijn de waarden van mijn Manifesto voor Agile Veranderen:

  • Betrekken van professionals en ruimte geven voor ideeën over standaardisatie en voorschrijven van werkprocessen
  • Stapsgewijze evolutionaire verbetering van binnen uit over top down opleggen van veranderingen.
  • Resultaatgericht en intensief samenwerken over directieve doelen met “command & control” management.
  • Prioritiseren en flexibel inspelen op kansen over budgetteren en veranderplannen uitvoeren.

De waarden aan de rechterkant van bovenstaande statements zijn en blijven belangrijk, maar ik geef graag meer aandacht aan de waarden aan de linkerkant. Daarom geef ik bijvoorbeeld de voorkeur aan het in kaart brengen van de bestaande werkprocessen met de medewerkers en samen werken aan verbetering mbv retrospectives in plaats van organisatiebreede uitrol van Scrum met standaard trainingen. En werk ik liever met een veranderbacklog waarin de prioriteiten eenvoudig aan te passen zijn dan met een plan. Ook veranderen veranderd

Anders dan het Agile Manifesto wat al 15 jaar hetzelfde is verwacht ik dat dit manifesto wel zal veranderen. De eerste evolutie is al te zien als je het vergelijkt met het verander manifesto van veranderproject, een samenwerkingsverband van enkele jaren geleden. Bijvoorbeeld woorden als “verbinden” zijn verder uitgewerkt in “resultaatgericht en intensief samenwerken” en het manifesto voor agile veranderen benoemd de rol van de professional en een bottom up aanpak voor verandering.

In de nabije toekomst zal ik diverse artikelen publiceren waarin ik dieper in ga op de waarden van dit manifesto. Ik geef daarin o.a. voorbeelden van betrekken van professionals in verandertrajecten, top-down versus bottom up veranderen, evolutionaire versus revolutionaire verandering en resultaatgericht veranderen.

Categories: Blogs

All languages bundle for Valuable Agile Retrospectives

Ben Linders - Thu, 07/07/2016 - 16:00

Valuable agile retrospectives - all languages bundleThe successful book Getting Value out of Agile Retrospectives has been translated in many languages. The leanpub bundle Valuable Agile Retrospectives – All Languages contains all language editions, you can get 9 books for the reduced price of $24,99 (excluding VAT).

People from all over the world approach us for translating our book into their native language. We love to work together with local agile communities and agile practitioners to make our book available in their local language.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

The normal price for the 9 books is $89,91, together these books are now available for the price of $24,99, a discount of more that 70%. When you buy the bundle you will get all translations that are released in the future for free. With this bundle you will always have the latest version of our book in every language.

Our mission is to help many teams all around the world to get more value out of agile retrospectives.

At this moment out book is available in these languages on leanpub:
[Nederlands]  [Español]  [Francais]  [Japanese]  [Italiano]  [Chinese]  [русский]  [Polish]

You can buy all local language editions of Getting Value out of Agile Retrospectives at Amazon.com (and all other Amazon shops), LeanpubiTunesSmashwordsLuluBarnes & NobleKoboScribd, Oyster and Blio. Paperback editions can be bought in my webshop and on bol.com and Managementbook.nl.

Categories: Blogs

Knowledge Sharing


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