Skip to content

Blogs

Critical factors for effective distributed teams


With distributed teams, it is very easy to develop an us vs them relationship.  There is a whole lot of informal interaction that occurs when we're co-located that don't happen when we're separated.  A lot of this random interaction might seem trivial and pointless but it all contributes to remind us that we're dealing with humans and not faceless entities.  This is essentially about propinquity.
Critical Factor #1: Increase the amount of informal interaction to humanise relationships
Some techniques I've seen that have been useful include:
  • Always-on video conferencing.  If there's too much background noise, mute sending on each side which allows you to un-mute to call out to the other side for ad-hoc communication.
  • Flying people to visit to and from each location.  This is especially useful at the start but also needs to be done regularly during the entire delivery.
  • Electronic collaboration tools like chat rooms, Yammer, etc.
Although, it's important to increase the humanising interactions, it's also important to reduce the amount of interactions required to do the actual work.  No matter what we do, it's harder to communicate across locations compared to the same location.
Critical Factor #2: Decrease the amount of communication across locations required for doing the work
Some techniques I've seen that have been useful include:
  • Separation of work across locations by self-contained capability, not by function.  This typically requires a loosely coupled architecture, for example microservices.
  • Integration contract tests.  A lot of ongoing communication is related to clarifying unclear expectations.  Integration contract tests are a way to be much more explicit and concrete about expectations as well as provide a trigger for when expectations are diverging thus requiring communication.
Co-location compensates for many team practices that would otherwise be ineffective.  Problems that seem small in a co-located context become very large when distributed.  Before you scale up a distributed setup, you should already be able to detect the types of problems you'll face from a co-located setup, but the problems will just seem very small.
Critical Factor #3: Sweat the mundane details.  Minor issues when co-located are major issues when distributed.
A particular mundane detail that I've seen that is critical is...
  • Keeping the communication technology working no matter what.  A common error is not forecasting expected demand in bandwidth to support video conferencing as the number of teams grow.
Categories: Blogs

R: Converting a named vector to a data frame

Mark Needham - Sat, 11/01/2014 - 01:47

I’ve been playing around with igraph’s page rank function to see who the most central nodes in the London NoSQL scene are and I wanted to put the result in a data frame to make the data easier to work with.

I started off with a data frame containing pairs of people and the number of events that they’d both RSVP’d ‘yes’ to:

> library(dplyr)
> data %>% arrange(desc(times)) %>% head(10)
       p.name     other.name times
1  Amit Nandi Anish Mohammed    51
2  Amit Nandi Enzo Martoglio    49
3       louis          zheng    46
4       louis     Raja Kolli    45
5  Raja Kolli Enzo Martoglio    43
6  Amit Nandi     Raja Kolli    42
7       zheng Anish Mohammed    42
8  Raja Kolli          Rohit    41
9  Amit Nandi          zheng    40
10      louis          Rohit    40

I actually had ~ 900,000 such rows in the data frame:

> length(data[,1])
[1] 985664

I ran page rank over the data set like so:

g = graph.data.frame(data, directed = F)
pr = page.rank(g)$vector

If we evaluate pr we can see the person’s name and their page rank:

> head(pr)
Ioanna Eirini          Mjay       Baktash      madhuban    Karl Prior   Keith Bolam 
    0.0002190     0.0001206     0.0001524     0.0008819     0.0001240     0.0005702

I initially tried to convert this to a data frame with the following code…

> head(data.frame(pr))
                     pr
Ioanna Eirini 0.0002190
Mjay          0.0001206
Baktash       0.0001524
madhuban      0.0008819
Karl Prior    0.0001240
Keith Bolam   0.0005702

…which unfortunately didn’t create a column for the person’s name.

> colnames(data.frame(pr))
[1] "pr"

Nicole pointed out that I actually had a named vector and would need to explicitly extract the names from that vector into the data frame. I ended up with this:

> prDf = data.frame(name = names(pr), rank = pr)
> head(prDf)
                       name      rank
Ioanna Eirini Ioanna Eirini 0.0002190
Mjay                   Mjay 0.0001206
Baktash             Baktash 0.0001524
madhuban           madhuban 0.0008819
Karl Prior       Karl Prior 0.0001240
Keith Bolam     Keith Bolam 0.0005702

We can now sort the data frame to find the most central people on the NoSQL London scene based on meetup attendance:

> data.frame(prDf) %>%
+   arrange(desc(pr)) %>%
+   head(10)
             name     rank
1           louis 0.001708
2       Kannappan 0.001657
3           zheng 0.001514
4    Peter Morgan 0.001492
5      Ricki Long 0.001437
6      Raja Kolli 0.001416
7      Amit Nandi 0.001411
8  Enzo Martoglio 0.001396
9           Chris 0.001327
10          Rohit 0.001305
Categories: Blogs

Partnerships & Possibilities, Episode 3, Season 6

Partnership & Possibilities - Diana Larsen - Fri, 10/31/2014 - 13:51

Partnerships & Possibilities: A Podcast on Leadership in Organizations
EPISODE 3: THE DIFFERENT FACES OF LEADERSHIP


Photo Credit: Victoria Nevland via Compfight cc

[introduction] How do things get done on a self-organizing team? It seems like nobody is directing the work…

[3:55] As a manager, knowing what leadership roles you need covered on a team would help to populate your teams.

[5:30] Look for T-shaped team members, and “Pi-shaped” team members, for bench strength.

[9:30] Knowing these roles could help you charter your team.

[10:10] Pioneer and Instructor roles are the early adopters of new ideas.

[11:40] Influencer and Follower roles.

[13:25] Commentator, Advocate, and Coordinator roles.

[16:35] CAUTION: All these roles are not job titles – they are roles that some or all team members may fluidly move in and out of from time to time.

[19:50] The Promoter, Mentor, and Peacemaker roles.

[23:00] The Critic, Gatekeeper, Dissenter.

[26:20] The Reviewer and the Monitor.

Shared Leadership Roles PDF

Categories: Blogs

hdiutil: could not access / create failed – Operation canceled

Mark Needham - Fri, 10/31/2014 - 11:45

Earlier in the year I wrote a blog post showing how to build a Mac OS X DMG file for a Java application and I recently revisited this script to update it to a new version and ran into a frustrating error message.

I tried to run the following command to create a new DMG file from a source folder…

$ hdiutil create -volname "DemoBench" -size 100m -srcfolder dmg/ -ov -format UDZO pack.temp.dmg

…but was met with the following error message:

...could not access /Volumes/DemoBench/DemoBench.app/Contents/Resources/app/database-agent.jar - Operation canceled
 
hdiutil: create failed - Operation canceled

I was initially a bit stumped and thought maybe the flags to hdiutil had changed but a quick look at the man page suggested that wasn’t the issue.

I decided to go back to my pre command line approach for creating a DMG – DiskUtility – and see if I could create it that way. This helped reveal the actual problem:

2014 10 31 09 42 20

I increased the volume size to 150 MB…

$ hdiutil create -volname "DemoBench" -size 100m -srcfolder dmg/ -ov -format UDZO pack.temp.dmg

and all was well:

....................................................................................................
..........................................................................
created: /Users/markneedham/projects/neo-technology/quality-tasks/park-bench/database-agent-desktop/target/pack.temp.dmg

And this post will serve as documentation to stop it catching me out next time!

Categories: Blogs

The Agile Reader – Weekend Edition: 10/31/2014

Scrumology.com - Kane Mar - Fri, 10/31/2014 - 08:26

You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @BlancheSabb: [CDP] Connaissez-vous la différence entre #ScrumMaster dédié & #ScrumMaster intégré ? #agile http:/…
  • ☆★☆ JOB ALERT ☆★☆ #Job #Atlanta – Scrum Master / Agile Coach view full details
  • ☆★☆ JOB ALERT ☆★☆ #Job #Auburn Hills – Agile PM/Scrum Master view full details
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agile #scrum
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • Dot Net Technical Lead / C# Software Developers (Agile/Scrum) (Colombo 01) http://t.co/NgAw2wU017
  • RT @MasterScrum: What Does QA do on the First Day of a Sprint? #agile #scrum http://t.co/180ciIpkkt
  • RT @MasterScrum: User Acceptance Testing in #Scrum #Agile
    The transparency and customer collaboration that… http:…
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • #jobs4u #jobs Agile Project Manager with Banking experience and Scrum Certified, [Chicago, #IL] #banking
  • RT @jobz4banking: #jobs4u #jobs Agile Project Manager with Banking experience and Scrum Certified, [Chicago, #IL] #b…
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • ☆★☆ JOB ALERT ☆★☆ #Job #Atlanta – Scrum Master / Agile Coach view full details
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @cgougler: RT @iovation: #Scrum Stories. Lessons from an #agiledevelopment Development Luminary @rlunde @TotherAl…
  • Agile Canada » Project Manager / Agile Scrum Manager at Recruitment Rocket (Halifax, NS):… #Canada #Agile #Jobs
  • RT @cgougler: RT @iovation: #Scrum Stories. Lessons from an #agiledevelopment Development Luminary @rlunde @TotherAl…
  • “Scrum cannot work w/o XP” ~ @jbrains on the Fundamental Theorem Of Agile Software Development h/t @YvesHanoulle
  • RT @dfkaye: “Scrum cannot work w/o XP” ~ @jbrains on the Fundamental Theorem Of Agile Software Development h/t @Yves…
  • #new_comment on ‘Training and retaining the basics of ..’ #AgileIndia2015 @ConfEngine. Your feedback?
  • #Agile – What does Self-Organizing team mean? – http://t.co/IyaiqR2ZZm
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • Agile Canada » Project Manager / Agile Scrum Manager at Recruitment Rocket (Halifax, NS):… #Canada #Agile #Jobs
  • A #scrum master is a member of the scrum team – not its boss. #agile ^ @ryanripley
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • What does the Scrum Master actually do in agile projects? – http://t.co/GkYERi0wzl
  • Categories: Blogs

    Another example of Object Theater

    Matteo Vaccari - Thu, 10/30/2014 - 19:37
    Mastermind

    This year I gave my Web Applications students the task of writing a Mastermind game. You can see some of their work here, here and here. The game works like this: the computer starts a new game by inventing a random secret code, composed of 4 digits from 1 to 6. For instance: 5414.

    The player must deduce what is the secret code by trying guesses. To continue the example if my first guess is 1234, the computer will answer “-+” which means that I got one number right (+) and another number is present in the secret code but in a different position (-). Of course, I don’t know which! I can then try more guesses, until I have enough clues to guess right.

    You get a score for each completed game, that is equal to the number of guesses. Of course, the lower the score, the better.

    A player will earn a score that is the average of all the games he or she completed.

    Procedural!

    Teaching Object-Oriented programming was not one of the goals of the course. Therefore, most programs I got were very procedural. (Please note that the example that follows is from a good student and his work earned a very high score in my course. It was a good web application, even though it was not object-oriented).

    I’d like to show an example of procedural code. This is a controller object that handles a “guess”.

    public void guess() throws IOException {
      String gameId = request.getParameter("game_id");
      String code = gamesRepository.findSecretCode(gameId);
      String guess = request.getParameter("guess");
      String answer = compareCodes(code, guess);
      String player = gamesRepository.find_game_player(gameId);
      guessesRepository.createGuess(gameId, player, guess, answer);
      gamesRepository.incrementGameScore(gameId);
    
      // if game is won
      if(answer.equals("++++")){
        gamesRepository.setFinished(request.getParameter("game_id"));
        int oldScore = gamesRepository.getPlayerScore(player);
        playersRepository.addFinishedGame(player, oldScore);
      }
    
      // return json data
      response.getWriter().write(toJson("answer", answer));
    }
    

    This is classic procedural code; the game logic is found in the controller (method compareCodes()) and the repositories (three repositories!). There are no domain objects.

    The database structure is something like

           1      *      1      *
    player -------- game -------- guesses
    

    The gameRepository adds a row to the games table when a new game is added. The guessesRepository adds a row to the guesses table when a new guess is guessed. The controller must take care to call the proper repositories at the right time. The controller “knows” the database structure; if the database structure changes, the controller code will probably also change.

    Object-Oriented

    What I’d like to do instead is

    • Domain objects that handle all the game logic
    • No logic in the repositories or the controller
    • Just one repository is enough, thank you. The repository should take care of adding rows to the proper tables.

    The domain object should probably be the MasterMind game.

    game.guess(request.getParameter("guess"));
    

    The “guess” message is what sets the domain logic in motion. The controller should not need to know anything else.

    Q. What if the game is won? Who updates the player’s score?

    A. The game object should do that.

    Q. Where do we see that the game updates the player’s score?

    A. Not in the controller. The controller does not know or care. Handling victories is something that is done in the game object.

    Q. Really! How do we update the player’s score?

    A. The game probably knows its player, and tells it to update its score if the game is won.

    Q. How does the game get a reference to its player?

    A. The controller does not know. But see next question.

    Q. Where do we get the game object from?

    A. From a repository, of course. We suppose that the repository will return it with all the dependencies that it needs to have. If the game needs a reference to its player, the repository must take care to set it up.

    String gameId = request.getParameter("game_id");
    Game game = gamesRepository.findGame(gameId);
    
    game.guess(request.getParameter("guess"));
    

    Q. How is the state of the game persisted?

    A. By asking the repository to save the game.

    // Here we are in the infrastructure world
    String gameId = request.getParameter("game_id");
    Game game = gamesRepository.findGame(gameId);
    
    // Now we pass to the realm of pure domain logic
    game.guess(request.getParameter("guess"));
    
    // And now we return to the infrastructure world
    gamesRepository.save(game);
    response.getWriter().writer(toJson(game));
    

    So we have seen another example of object theater. The infrastructure details are dealt with before and after the main action. The main action is sending “guess” to the game object. There is where the functional requirements is dealt with. Before that, and after that, is infrastructure code that deals with non-functional, performance requirements.

    Categories: Blogs

    Driving Business Transformation by Reenvisioning Your Customer Experience

    J.D. Meier's Blog - Thu, 10/30/2014 - 18:03

    You probably hear a lot about the Mega-Trends (Cloud, Mobile, Social, and Big Data), or the Nexus of Forces (the convergence of social, mobility, cloud and data insights patterns that drive new business scenarios), or the Mega-Trend of Mega-Trends (Internet of Things).

    And you are probably hearing a lot about digital transformation and maybe even about the rise of the CDO (Chief Digital Officer.)

    All of this digital transformation is about creating business change, driving business outcomes, and driving better business results.

    But how do you create your digital vision and strategy?   And, where do you start?

    In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of their lessons learned from companies that are digital masters that created their digital visions and are driving business change.

    3 Perspectives of Digital Vision

    When it comes to creating your digital vision, you can focus on reenvisioning the customer experience, the operational processes, or your business model.

    Via Leading Digital:

    “Where should you focus your digital vision? Digital visions usually take one of three perspectives: reenvisioning the customer experience, reenvisioning operational processes, or combining the previous two approaches to reenvision business models.  The approach you take should reflect your organization’s capabilities, your customer’s needs, and the nature of competition in your industry.”

    Start with Your Customer Experience

    One of the best places to start is with your customer experience.  After all, a business exists to create a customer.  And the success of the business is how well it creates value and serves the needs of the customer.

    Via Leading Digital:

    “Many organizations start by reenvisioning the way they interact with customers.  They want to make themselves easier to work with, and they want to be smarter in how they sell to (and serve) customers.  Companies start from different places when reenvisioning the customer experience.”

    Transform the Relationship

    You can use the waves of technologies (Cloud, Mobile, Social, Data Insights, and Internet of Things), to transform how you interact with your customers and how they experience your people, your products, and your services.

    Via Leading Digital:

    “Some companies aim to transform their relationships with their customers.  Adam Bortman, chief digital officer of Starbucks, shared this vision: 'Digital has to help more partners and help the company be the way we can ... tell our story, build our brand, and have a relationship with our customers.' Burberry's CEO Angela Ahredts focused on multichannel coherence. 'We had a vision, and the vision was to be the first company who was fully digital end-to-end ... A customer will have total access to Burberry across any device, anywhere.'  Mare Menesquen, managing director of strategic marketing at cosmetics gitan L'Oreal, said, 'The digital world multiples the way our brands can create an emotion-filled relationship with their customers.’”

    Serve Your Customers in Smarter Ways

    You can use technology to personalize the experience for your customers, and create better interactions along the customer experience journey.

    Via Leading Digital:

    “Other companies envision how they can be smarter in serving (and selling to) their customers through analytics.  Caesars started with a vision of using real-time customer information to deliver a personalized experience to each customer.  The company was able to increase customer satisfaction and profits per customer using traditional technologies.  Then, as new technologies arose, it extended the vision to include a mobile, location-based concierge in the palm of every customer's hand.”

    Learn from Customer Behavior

    One of the most powerful things you can now do with the combination of Cloud, Mobile, Social, Big Data and Internet of Things is gain better customer insights.  For example, you can learn from the wealth of social media insights, or you can learn through better integration and analytics of your existing customer data.

    Via Leading Digital:

    “Another approach is to envision how digital tools might help the company to learn from customer behavior.  Commonwealth Bank of Australia sees new technologies as a key way of integrating customer inputs in its co-creation efforts.  According to CIO Ian Narev, 'We are progressively applying new technology to enable customers to play a greater part in product design.  That helps us create more intuitive products and services, readily understandable to our customers and more tailored to their individual needs.”

    Change Customers’ Lives

    If you focus on high-value activities, you can create breakthroughs in the daily lives of your customers.

    Via Leading Digital:

    “Finally, some companies are extending their visions beyond influencing customer experience to actually changing customers' lives.  For instance, Novartis CEO Joseph Jimenez wrote of this potential: ‘The technologies we use in our daily lives, such as smart phones and tablet devices, could make a real difference in helping patients to manage their own health.  We are exploring ways to use these tools to improve compliance rates and enable health-care professionals to monitor patient progress remotely.’”

    If you want to change the world, one of the best places to start is right from wherever you are.

    With a Cloud and a dream, what can you do to change the world?

    You Might Also Like

    10 High-Value Activities in the Enterprise

    Cloud Changes the Game from Deployment to Adoption

    The Future of Jobs

    Management Innovation is at the Top of the Innovation Stack

    McKinsey on Unleashing the Value of Big Data

    Categories: Blogs

    Object-Oriented Theater

    Matteo Vaccari - Thu, 10/30/2014 - 17:34

    Update 30/10/14: I first read about the “Object Theatre” in a message by Anthony Green on the GOOS mailing list; I didn’t remember it consciously when I wrote this post, but it certainly has been working in my brain ever since. The “Object Theatre” metaphor is his invention, not mine. Thanks Kevin and Anthony for pointing it out.

    Yesterday evening I attended a good introduction on functional programming by Mario Fusco. One of his slides illustrated a well-known principle of functional programming. There are pure functions, and “functions” with side effects. Good FP style suggests to keep non-pure functions at the edges of the program, so that the inner core of your program only contains pure, mathematical functions.

    He showed this picture

    http://www.slideshare.net/mariofusco/if-you-think-you-can-stay-away-from-functional-programming-you-are-wrong/41

    In fact, a very similar picture can be drawn for good object-oriented style. In good OO style, you want to separate your domain objects from infrastructure objects. The domain objects contain just domain logic, they execute in memory and have no references to file system, databases or network services. They can be mutable, of course! But they are “pure logic” in the sense that they live in a platonic world where we are only concerned with the functional behaviour of our programs.

    Infrastructure objects, on the other hand, deal with everything else: user interface, databases, file systems, web services… All the things that are needed to connect our platonic world of objects to the outside world.

    So what’s good OO style in this context? In my opinion, it’s good to keep the infrastructure objects in an outside shell, while the inner core of the program contains only pure domain objects. Let me give you an example.

    Suppose you have a Counter object that needs (for non-functional reasons!) to be made persistent. The functional logic is about incrementing and decrementing the value of the counter. The infrastructure logic is about making sure that the counter retains its value across reboots (which is definitely a non-functional requirement.)

    The wrong way to do this is

    // bad style! don't do this
    class Counter {
      public Counter(int id, CounterDao dao) {
        this.id = id;
        this.dao = dao;
      }
    
      public void increment() {
        value++;
        dao.incrementCounter(id);
      }
    
      private int value = 0;
      private int id;
      private CounterDao dao;
    }
    

    The usage of this counter would be

    CounterDao dao = ...;
    Counter counter = new Counter(123, dao);
    
    // here we perform logic and also persist the state
    counter.increment();
    

    The above example is bad style, because it mixes persistency logic with functional logic. Bah! A better way to do it is:

    class Counter {
      public void increment() {
        value++;
      }
      private int value = 0;
    }
    

    See? Only pure logic. We don’t care about persistency there. We could use the counter this way:

    // we start this use case in the world of infrastructure
    CounterDao dao = ...;
    Counter counter = dao.findCounter(id);
    
    // here we enter the world of pure logic
    counter.increment();
    
    // here we return to the world of infrastructure
    dao.save(counter);
    

    I like to call this structure “object theatre”. Imagine your domain objects as actors in a play. You want to setup a scene where your actors are set up in a certain way: Arlecchino talks to Colombina, Colombina has a fan in her hand, etc. When the scene starts, the actors perform each according to their character. When the scene ends, we lower the curtain.

    I imagine that an object-oriented system works the same way. When a request arrives, we set up the scene by retrieving all the proper objects from various repositories and we connect them appropriately. This is setting the scene. Then we send a message to one object that sets some logic in motion. The objects send messages to each other, carrying out a computation. This is playing out the scene. When the domain objects are done, we conclude by returning the objects to their respective repositories. This is lowering the curtain.

    Categories: Blogs

    SAFe Overview Video by Inbar Oren

    Agile Product Owner - Thu, 10/30/2014 - 17:32

    Inbar Oren, the maker of the short and fun “SAFe 3.0 in 9 minutes video” (see http://scaledagileframework.com/foundations/), recently presented an overview of SAFe to an audience at Adventures in Agile meet-up in London. Of course, it took him longer than nine minutes, but you can learn a lot more about SAFe in this video:

    https://www.youtube.com/watch?v=9TJDobOJMQw

    Thanks Inbar!

    Categories: Blogs

    Agile Quick Links #25

    Notes from a Tool User - Mark Levison - Thu, 10/30/2014 - 12:08
    AgileSome interesting reading for the Agile community:
    Categories: Blogs

    Agile Smells Versus Agile Zombies in the Uncanny Valley

    Leading Agile - Mike Cottmeyer - Thu, 10/30/2014 - 07:00
    Code Smell

    A code smell is a hint that something may have gone wrong somewhere in your source code. Martin Fowler included the term smell in his book Refactoring way back in 2000, referring to something that may not be right. Just because something smells, it does not mean there is a problem; it does mean, however, that there should be further investigation.

    Agile Smell

    Similar to a code smell, Agile smell is a hint that something may have gone wrong somewhere in your Agile practices.  Be it a variation in the length of iterations, volatility in velocity, or having teams where the ScrumMaster is also the Product Owner, these smells are out there with every client I’ve met.  The thing is, the further you get from textbook Scrum, the harder it becomes to sniff out potential problems.

    Uncanny Valley

    I don’t like to use the term smell. I prefer to say that you’re in “the valley”.  I’m referring to the uncanny valley.  When something looks and moves almost, but not exactly, like a healthy person, it causes a response of revulsion among some observers. The “valley” refers to the dip in a graph (see below) of the comfort level of observers. Ever watch Polar Express?  Though it is a kids movie, it creeps the hell out of me and it makes me feel really uneasy. The characters look pretty real but their movement is just a little off and their eyes look dead.  That uneasiness I feel is the uncanny valley.  To that, I believe there is an Agile uncanny valley and it’s full of Agile zombies.

    uncanny valley

    Agile Zombie

    Potential problems with Agile practices are out there but many people are oblivious to them.   I’ve seen customers rely on people who have  certifications but no experience. I’ve seen customers rely on trainers or salesmen, who talk about ideal situations in a conceptual world.  This is off-putting to me and I label that persona the Agile zombie.  It’s like the Polar Express all over again.  To smell problems at scale, you need coaches or consultants who have been dropped into multiple situations and have the tools and techniques to get a read on things lickedy split.  This is one reason we do assessments.  We need to know where you are.  We may find you are doing a great job.  We may also find you are deep in the valley.

    Uncanny Agile Valley

    People do or say things that sound benign on the surface but when you ask them why a few times, you realize something isn’t quite right.  Do you conduct ceremonies or follow a governance but don’t know why? You may be in the valley.  Do you hyperfocus on metrics without considering how they could negatively impact the behaviour of your teams or why you’re collecting the data? You may be in the valley.  Do you structure your teams without thoughts of dependencies or scaling? You may be in the valley.  Do you evangelize practices but don’t know if they are appropriate, based on organizational goals?  That’s right, you may be in the valley.

    Are you in the valley?

    The post Agile Smells Versus Agile Zombies in the Uncanny Valley appeared first on LeadingAgile.

    Categories: Blogs

    Candy or Death: The Automatic Halloween Candy Dispenser

    Radyology - Ben Rady - Thu, 10/30/2014 - 05:59
    Let's start with a word problem. Assume you live in a busy trick-or-treating neighborhood and that, on average, a group of four rings your doorbell every minute and takes 1/2 oz of candy per person. If you leave a bowl... Ben Rady
    Categories: Blogs

    Agile Homeschool Update

    Agile For All - Bob Hartman - Thu, 10/30/2014 - 00:01

    Last year, I wrote about how we use an agile approach for homeschool.

    Since then, we’ve refined our approach. This school year, we updated our board to reflect some of those changes.

    Agile Homeschool Board 1

    Agile Homeschool Board 2

    A few things to note about our board:

    1. We have a Scheduled swim lane at the top for calendar items that will affect how much other schoolwork we can plan in a day. Usually music lessons, bike practice, and field trips end up here. These cards don’t move, they just help everyone avoid overcommitting.
    2. There’s a swimlane for things that need to be done together. In the morning, everyone will agree when to do this. When our boys were younger, this swimlane was much more full. These days, work is more independent.
    3. The remaining four swimlanes are for individual work. My wife, Dawn, and each of our three boys have their own lanes. Each day, they pull from two input queue columns—the one for the day, which is work that has to be done that day, and the Anytime column, which is work that just needs to happen sometime that week.
    4. Though we don’t call it out on the board, we have a WIP limit of 1 per person on Doing.
    5. In the individual swimlanes, color indicates policy and work item type. Pink cards can go straight to Done. Yellow cards need to go to Ready for Review. Dawn or I will review the work and either move it to Done or add a corrections sticky to the original sticky and move it back into an input queue. Orange cards are chores rather than schoolwork.

    Every Friday afternoon, we plan for the next week and refill the board. This takes a little while, so we’ve made the board so it hangs on hooks in the laundry room and can be moved. That way, we can plan somewhere more comfortable.

    The core of the board is still the standard Planned → In Progress → Done workflow, but we’ve added variations that allow us to make better decisions about what to do at any particular moment.

    The post Agile Homeschool Update appeared first on Agile For All.

    Categories: Blogs

    Spark the Change Toronto – Pre-Registration Started

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

    This looks like a great conference – to be held on Thursday, April 23rd, 2015.  From the description:

    An event for the whole organization, Spark brings together leaders from across the business to explore how they can work together to create lasting and total change. Talks and workshops offer inspiring examples and practical advice on taking action and overcoming obstacles. – See more at: http://2015.sparkthechange.ca/what-is-spark-2/#sthash.WI3bDFBA.dpuf

    Sign up for pre-registration for Spark the Change Toronto

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

    The Magic and Science of Teams

    Notes from a Tool User - Mark Levison - Wed, 10/29/2014 - 17:02

    While in Florida for Agile 2014, Mark was interviewed by InfoQ about “The Magic and Science of Teams”.

    Mark Levison on the Magic and Science of Teams
    Mark explains that there are some exciting things happening as years of research in basic studies of teams in organizations combines with behavioural psychology and neuroscience, and recent access to large data sets. This all creates a science that can be applied to help develop high performance teams, which is Mark’s specialty.

    You can access the full video with transcript of “Mark Levison on the Magic and Science of Teams” here.

    Certified Scrum Trainer Mark Levison offers insight into the neuroscience of teams with five proven Agile methods to create teams that sizzle not fizzle. Get a FREE copy of Five Steps Towards Creating High-Performance Teams when it is published and put your team on the path to high-performance success.

    Register to get a
    FREE advance copy of
    5 Steps Towards Creating High-Performance Teams * indicates required Email Address *

    First Name *

    Last Name *

    Categories: Blogs

    Azure Mobile Services with AutoMapper

    Jimmy Bogard - Wed, 10/29/2014 - 15:23

    At the recent Xamarin Evolve conference, Paul Batum gave a great talk on Azure Mobile Service in cross-platform business apps, part of which included a piece on how AutoMapper fits in with their overall system:

    There were sooooo many of those C# shirts at the conference, I felt a little left out without one.

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

    Categories: Blogs

    Scrum “Inputs”

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

    The Product Backlog is often described as the primary input to Scrum.  The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog.  In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog.  And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role.  I believe in just starting if you can.  I even wrote a blog post about this a while back and I stand by it.

    I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing.  Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start.  And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.

    The Scrum Guide recognizes the following inputs to Sprint Planning:

    • Product Backlog
    • Latest product increment (not applicable to first Sprint)
    • Projected capacity of the Development Team during the Sprint
    • Past performance of the Development Team (not applicable to first Sprint)
    • Definition of “Done” (implicitly)

    A newly-formed team often needs to address the following before the first Sprint:

    • Product Backlog
    • Projected capacity of the Development Team during the Sprint
    • Definition of “Done”

    If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).

    Product Backlog

    Keep it simple.  It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product.  Get the Product Owner to blow these things out into a list.  It doesn’t need to be a complete list.  Just the most important things right now.  A good test is to give the Product Owner 5 minutes.  Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on.  There are all kinds of techniques that can be used to order the Product Backlog.  The simplest way is to just have the Product Owner eyeball it.  If people are uncomfortable with this, then introduce the other ways.  It doesn’t need to be perfect.  It will get better and become refined and adapted as you go.

    Projected capacity of the Development Team during the Sprint

    Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%).  If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post.  According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).

    Definition of “Done”

    This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done.  The team needs to know this before it can estimate the items in the Product Backlog as a team.  Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.

    Planning with the Product Backlog, projected capacity and Definition of “Done”

    In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”.  Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done.  All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built.  The team should try to create a set of tasks each of which are a one-person day effort or less.  Count the number of tasks.  If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog.  If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.

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

    Comparing processing times of NServiceBus saga patterns

    Jimmy Bogard - Tue, 10/28/2014 - 19:16

    A few weeks ago I gave a talk at NSBCon NYC on scaling NServiceBus, and one of the pieces I highlighted were various saga/processing patterns and how they can affect performance. It was difficult to give real numbers as part of the discussion, mostly because how long it takes to do something is highly variable in the work being done and environmental constraints.

    I compared three styles of performing a set of distributed work:

    And highlighted the performance differences between them all. Andreas from the Particular team mentioned that some work had been done to improve saga performance, so I wanted to revisit my assumptions to see if the performance numbers still hold.

    I wanted to look at a lot of messages – say, 10K, and measure two things:

    • How long it took for an individual item to complete
    • How long it took for the entire set of work to complete

    Based on this, I built a prototype that consisted of a process of 4 distinct steps, and each variation of process control to track/control/observe progress. You can find the entire set of code on my GitHub.

    Here’s what I found:

    Process Total Time Average Median Observer 6:28 0.1 sec <0.1 sec Controller 6:25 3:25 3:37 Routing Slip 2:57 2.6 sec <0.1 sec

    Both the observer and controller styles took roughly the same total amount of time. This is mostly because they have to process the same total amount of messages. The observer took slightly longer in my tests, because the observer is more likely to get exceptions for trying to start the same saga twice. But once an item began in the observer, it finished very quickly.

    On the controller side, because all messages get funneled to the same queue, adding more messages meant that each individual item of work would have to wait for all previous items to complete.

    Finally, the routing slip took less than half the time, with higher total average but comparable median to the observer. On the routing slip side, what I found was that the process sped up over time as the individual steps “caught up” with the rate of incoming messages to start the process.

    This was all on a single laptop, so no network hops needed to be made. In practice, we found that each additional network hop from a new message or a DB call for the saga entity added latency to the overall process. By eliminating network hops and optimizing the total flow, we’ve seen in production total processing times decrease by an order of magnitude based on the deployment topology.

    This may not matter for small numbers of messages, but for many of my systems, we’ll have 100s of thousands to millions of messages dropped on our lap, all at once, every day. When you have this situation, more efficient processing patterns can alleviate pressure in completing the work to be processed.

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

    Categories: Blogs

    Five Tips for Tactical Management

    Johanna Rothman - Tue, 10/28/2014 - 19:15

    Sometimes, you just need to get on with the work. You need to give yourself some breathing room so you can think for a while. Here are some tips that will help you tackle the day-to-day management work:

    1. Schedule and conduct your one-on-ones. Being a manager means you make room for  the people stuff: the one-on-ones, the coaching and feedback or the meta-coaching or the meta-feedback that you offer in the one-on-ones. Those actions are tactical and if you don’t do them, they become strategic.
    2. As a manager, make sure you have team meetings. No, not serial status meetings. Never those. Problem solving meetings, please. The more managers you manage, the more critical this step is. If you miss these meetings, people notice. They wonder what’s wrong with you and they make up stories. While the stories might be interesting, you do not want people making stories up about what is wrong with you or your management, do you?
    3. Stop multitasking and delegate. Your people are way more capable than you think they are. Stop trying to do it all. Stop trying to do technical work if you are a manager. Take pride in your management work and do the management work.
    4. Stop estimating on behalf of your people. This is especially true for agile teams. If you don’t like the estimate, ask them why they think it will take that long, and then work with them on removing obstacles.
    5. If you have leftover time, it’s time to work on the strategic work. What is the most important work you and your team can do? What is your number one project? What work should you not be doing?  This is project portfolio management. You might find it difficult to make these decisions. But the more you make these decisions, the better it is for you and your group.

    Okay, there are your five tips. Happy management.

    Categories: Blogs

    ScanAgile 2015 submissions are open!

    Software Development Today - Vasco Duarte - Tue, 10/28/2014 - 19:15


    Just a quick note today to let you know that the Call for Sessions for ScanAgile, the Agile Finland annual conference is open for submissions.
    You can read the whole call for sessions here. You will find the submission form in that page as well.

    For me the most interesting tracks are:

    • Off-Piste: interesting lessons learned about being agile and agile related topics, from other industries 
    • Black Piste: Topics for experienced agile practitioners
    These are just some of the tracks. In Scan Agile there will also be tracks for those starting up or that have already started but are in the early phases of their Agile transformation journey. 


    The Agile Finland Community is very active and has a long history of agile adoption and promotion. They have some of the most advanced practitioners in the world, so I am really looking forward to see who the Scan Agile team chooses for the 2015 lineup of the conference! 


    Hope to see many of you there! 
    Categories: Blogs