Skip to content

Feed aggregator

The Agile Reader – Weekend Edition: 11/14/2014

Scrumology.com - Kane Mar - Fri, 11/14/2014 - 07:38

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 @vanesa_tejada: En RUMBO buscamos Scrum Masters, ¿te interesa? Entonces aquí tienes mas detalles: #empleo #agile …
  • Agile is Not Only for Software Projects #agile #scrum #pmot #lean
  • RT @yochum: Agilitrix – Michael Sahota: People over Process #agile #scrum
  • What kind of rewards should we use in our organisations? – #performancereviews #agile #scrum
  • ☆★☆ JOB ALERT ☆★☆ #Job #Dallas – IT Business Analyst/PM – Agile/Scrum view full details
  • RT @scrumology: Do you know how to scale Scrum? #Scrum #Agile
  • RT @vanesa_tejada: En RUMBO buscamos Scrum Masters, ¿te interesa? Entonces aquí tienes mas detalles: #empleo #agile …
  • You need @trello! It’s like organization powered by rocket fuel. (And it’s free!) #scrum #agile #projectmanagement
  • #scrum #DesingThinking #agile Caceres 4 de diciembre en el @CEEI_Ex
  • RT @antorecio: #scrum #DesingThinking #agile Caceres 4 de diciembre en el @CEEI_Ex
  • The four key tenets of #Scrum, still not followed enough #agile
  • RT @dozylocal: A lot (if not all) of this resonates with me. Nice summary :-) #agile #lean #scrum #mvp
  • Agile Scrum Master – RBC – Toronto, ON #JOBS #IT
  • RT @antorecio: #scrum #DesingThinking #agile Caceres 4 de diciembre en el @CEEI_Ex
  • Agile Canada » Agile Scrum Master – RBC – Toronto, ON: PMI certification as an Agile pra… #Canada #Agile #Jobs
  • RT @fancydev: A Scrum Master’s Practical Toolbox for creative Scrum Masters. @Scrumdotorg #agile #scrum http://t.co…
  • #LargeScaleScrum is now published on a website by Craig Larman and @basvodde #scrum #agile
  • OMG I was just tweeting :o I miss you twitter, will see you soon :) And agile/scrum rant is coming after #provoked
  • RT @yochum: Agilitrix – Michael Sahota: People over Process #agile #scrum
  • Denver CSM Class 12/8-9 w/ @skipangel #Scrum #Agile @RallySoftware http://t.co/2HqYgV1wXv
  • RT @yochum: On Software Development, Agile, Startups, and Social Networking – Isaac Sacolick: The Death of M… #agi…
  • RT @Astbrant: Great blog about UX… #RomanPichler #UXjayway #UX #Agile #Scrum
  • Agile Canada » Agile Scrum Master at RBC (Toronto, ON): agile team of 10 -15 cross functi… #Canada #Agile #Jobs
  • RT @JeanPierreTran: Waterfall vs. Agile vs. Lean, expliqué en une image #leanstartup #scrum
    http://t.co/7ahfhLu9yz
  • Subscribe now for my Q&A Agile Retrospectives Webinar: #scrum #agile #retrospectives
  • I liked a @YouTube playlist Agile Training (Scrum)
  • RT @vanesa_tejada: En RUMBO buscamos Scrum Masters, ¿te interesa? Entonces aquí tienes mas detalles: #empleo #agile …
  • RT @scrumology: Do you know how to scale Scrum? #Scrum #Agile
  • RT @vanesa_tejada: En RUMBO buscamos Scrum Masters, ¿te interesa? Entonces aquí tienes mas detalles: #empleo #agile …
  • Some recommendations for managing an outsourced software project. #pmot #agile #scrum
  • RT @lgoncalves1979: Subscribe now for my Q&A Agile Retrospectives Webinar: #scrum #agile #retrospectives
  • Throw Scrum Master out the window #agile #pmot #scrum
  • RT @vanesa_tejada: En RUMBO buscamos Scrum Masters, ¿te interesa? Entonces aquí tienes mas detalles: #empleo #agile …
  • RT @vanesa_tejada: En RUMBO buscamos Scrum Masters, ¿te interesa? Entonces aquí tienes mas detalles: #empleo #agile …
  • RT @vanesa_tejada: En RUMBO buscamos Scrum Masters, ¿te interesa? Entonces aquí tienes mas detalles: #empleo #agile …
  • Agile Scrum Master: RBC: “Purpose: Global Wealth Management Applications requires an… #software #jobs #toronto
  • Agile Canada » Project Manager/Agile Scrum Manager at More -> (Halifax, NS): management p… #Canada #Agile #Jobs
  • RT @MichikoDiby: Throw Scrum Master out the window #agile #pmot #scrum
  • Scrum Expert: Make Impacts Not Software #agile #scrum
  • RT @yochum: Scrum Expert: Make Impacts Not Software #agile #scrum
  • ☆★☆ JOB ALERT ☆★☆ #Job #Dallas – IT Business Analyst/PM – Agile/Scrum view full details
  • Agile by McKnight, Scrum by Day is out! Stories via @agilelynn @TheAgileNetwork @AgileUniversity
  • Emergent Design, The best results emerge from self-organizing teams… #agile #scrum @ScrumAlliance @martinalaimo
  • RT @MichikoDiby: Throw Scrum Master out the window #agile #pmot #scrum
  • 15% off for our Agile and Scrum workshop in Dublin, Ireland on 5th Dec 2014 at Dublin 8, Ireland #Dublin 8
  • Kanban & Agile Scrum: Is the Basic Concept Similar? #pmot #p http://t.co/HyCbcIEX57
  • RT @TalD: The Agile/ Scrum/ Lean Daily is out! Stories via @ADTmag @bradwilson @MariaMatarelli
  • RT @amckni: Agile by McKnight, Scrum by Day is out! Stories via @agilelynn @TheAgileNetwork @AgileUniversity
  • RT @lgoncalves1979: Subscribe now for my Q&A Agile Retrospectives Webinar: #scrum #agile #retrospectives
  • Categories: Blogs

    Guest blog: Retrospectives with Wordles

    Ben Linders - Fri, 11/14/2014 - 00:32
    There is a danger with retrospectives that teams will end up just going through the motions and not use the valuable material to identify whether the actions agreed at the end of the retrospective are actually making an impact on the team’s capability to improve. Furthermore, the chances are that in a multi-team environment, there are common themes raised that if highlighted early, can aid a new team when starting up – learn from others misfortune! Following the Agile philosophy of transparency, here at the UK Ministry of Justice we have been using Wordles to really get the key messages across in a clear manner. Continue reading →
    Categories: Blogs

    How To Abandon Practices

    NetObjectives - Thu, 11/13/2014 - 22:19
    We often hear no one size fits all, but then no one explains how to abandon the practices of what they preach. While Scrum is a great team framework, not all of the Scrum practices mandates in the framework should be used all of the time. In an earlier blog, The Right Way to Do Scrum-But I talked about the need to continue achieving the purpose of the abandoned practice. In this blog I'll give...

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

    Agile is Not Only for Software Projects

    TV Agile - Thu, 11/13/2014 - 22:01
    This presentation demonstrates specific practices for applying Agile concepts to all sorts of projects. It starts by reviewing the Agile concepts and then provide examples of Agile practices (and tools) applied to both software and non software projects. It will also describe how this particular set of Agile practices (called Commitment-based Project Management – CBPM) […]
    Categories: Blogs

    Make Impacts Not Software

    Scrum Expert - Thu, 11/13/2014 - 21:56
    Software is everywhere today, and countless software products and projects die a slow death without ever making any impact. Today’s planning and roadmap techniques expect the world to stand still while we deliver, and set products and projects up for failure from the very start. Even when they have good strategic plans, many organizations fail to communicate them and align everyone involved in delivery. The result is a tremendous amount of time and money wasted due to wrong assumptions, lack of focus, poor communication of objectives, lack of understanding and misalignment ...
    Categories: Communities

    Google Drive & Sign In Update

    Pivotal Tracker Blog - Thu, 11/13/2014 - 21:44

    Now you don’t even need to sign in with Google to add Drive files to your stories. Clicking the new Drive icon in an expanded story will either use the Google identity you are currently signed in with or prompt you to sign in to Google.

    DriveFilePicker

    Then if you haven’t already granted permission, you’ll see this to allow Tracker to show you (and NewDrivePermissiononly you) a list of your recent Drive files:

    Note: Even after they are added, no-one can open any of your Google files, unless you’ve shared those files with them in Drive.

    If you are signed in with more than one Google identity you might not see the Drive items you’re expecting. Google controls what’s displayed when you click the Drive icon, so please check which Google account you give (or gave) permission for.

    For those of you who do wish to sign in with Google, but not add Drive documents to stories, you might like to make sure access permissions are set correctly for that.

    Just sign out of Tracker then go to your Google Account’s Security page to remove account permissions for Tracker. Then, when you sign in to Tracker again with Google, you will only be asked to allow Tracker to view your email address and basic profile info.

    Also, a quick reminder that the “remember me” checkbox on the Tracker Sign in page, only applies to your Tracker login and password. Google’s equivalent is the “Stay signed in” option on their sign in page.

    We hope this is a welcome improvement, and would love to hear your feedback on what else you might like to be able to do with Tracker and Google together. So please let us know your ideas and questions via email (and follow us on Twitter for the latest Tracker news).

     

    The post Google Drive & Sign In Update appeared first on Pivotal Tracker.

    Categories: Companies

    Gatineau Ottawa Agile Tour 2014 (GOAT#14)

    Notes from a Tool User - Mark Levison - Thu, 11/13/2014 - 19:42
    GATINEAU OTTAWA AGILE TOURAgile Pain Relief is proud to be the Platinum sponsor for Gatineau Ottawa Agile Tour 2014.

    On November 24th, an expected 200+ Scrum and Agile professionals will gather in Gatineau for a one day conference that will feature two keynote speakers, 16 professional presentations, and coaches clinic among the opportunities.

    The conference’s keynote speakers this year will be Christopher Avery and Richard Cheng. Christopher is a sought-after speaker, author, and business advisor on responsible leadership, teamwork, and agile change for companies like GAP, Wells Fargo, and eBay, known for his cutting-edge work to demystify and then develop practical team leadership skills. And Richard is a Certified Scrum Trainer (CST) and Project Management Professional (PMP) with deep expertise in bringing Agile to commercial, non-profit, and Federal clients.

    Mark Levison will be one of 16 additional high-quality featured presentations, where he will present his High Performance Teams Game.

    As a Coach and a Team Member, I sometimes come across teams that don’t seem to be able to achieve high performance, and the reasons why aren’t apparent. This can be frustrating for everyone when this happens, so I wanted to explore this deeper and understand the science of what happens inside Agile/Scrum Teams.

    From his research and study, Mark has developed a game that will help attendees learn from their own experience some of what it takes to build high performance teams.

    Full details are available on the http://goagiletour.ca website. Tickets are limited and selling fast, so don’t delay. $70 registration ($25 student) includes presentations, breakfast and lunch, and up to 5 PDUs.

     

    Categories: Blogs

    Mobile authentication with Xamarin.Auth and refresh tokens

    Jimmy Bogard - Thu, 11/13/2014 - 15:46

    An internal app I’ve been working with for a while needed to use OAuth2 (specifically, OpenID Connect) to perform authentication against our Google Apps for Your Domain (GAFYD) accounts. Standard OAuth 1.0/2.0 flows are made easy with the Xamarin.Auth component. Since OpenID Connect is built on top of OAuth 2.0, the Xamarin.Auth component could suffice.

    A basic flow for using OAuth with Google APIs would look like this:

    image

    But for our purposes, we have a mobile application that connects to our APIs, but we simply want to piggyback on top of Google for authentication. So our flow looks more like:

    image

    This all works great straight out of the box, very nicely. One problem however – the token returned by the Google servers is only valid for a short period of time – 30 minutes or so. You *could* ignore this problem in the API we built, and not validate that part of the JWT. However, we don’t want to do that. Because we’re now going over the interwebs with our API calls, and potentially over insecure networks like coffee shop wi-fi, we want a solid verification of the JWT token:

    • The token’s hash matches
    • The issuer is valid (Google)
    • The allowed audience is correct – we only accept client IDs from our app
    • The certificate is signed against Google’s public OAuth certificates
    • The token has not expired

    This becomes a bit of a problem – the token expires very soon, and it’s annoying to log in every time you use the app. The Xamarin.Auth component supports storing the token on the device, so that you can authenticate easily across app restarts. However, out-of-the-box, Xamarin.Auth doesn’t support the concept of refresh tokens:

    image

    Since the refresh token is stored on the device, we just need to ask Google for another refresh token once the current token has expired. To get Xamarin.Auth to request a refresh token, we need to do a couple of things: first, override the GetInitialUrlAsync method to request a refresh token as part of getting an auth token:

    public override Task<Uri> GetInitialUrlAsync ()
    {
    	string uriString = string.Format (
    		"{0}?client_id={1}&redirect_uri={2}&response_type={3}&scope={4}&state={5}&hd=foo.com&access_type=offline&approval_prompt=force",
    		this.AuthorizeUrl.AbsoluteUri,
    		Uri.EscapeDataString (this.ClientId),
    		Uri.EscapeDataString (this.RedirectUrl.AbsoluteUri),
    		this.AccessTokenUrl == null ? "token" : "code",
    		Uri.EscapeDataString (this.Scope),
    		Uri.EscapeDataString (this.RequestState)
    	);
    
    	var url = new Uri (uriString);
    	return Task.FromResult (url);
    }
    

    The format of the URL is from Google’s documentation, plus looking at the behavior of the existing Xamarin.Auth component. Next, we create a method to request our refresh token if we need one:

    public virtual Task<int> RequestRefreshTokenAsync(string refreshToken)
    {
        var queryValues = new Dictionary<string, string>
        {
            {"refresh_token", refreshToken},
            {"client_id", this.ClientId},
            {"grant_type", "refresh_token"}
        };
    
    	if (!string.IsNullOrEmpty(this.ClientSecret))
    	{
    		queryValues["client_secret"] = this.ClientSecret;
    	}
    
    	return this.RequestAccessTokenAsync(queryValues).ContinueWith(result =>
    	{
    	    var accountProperties = result.Result;
    
    	    this.OnRetrievedAccountProperties(accountProperties);
    
            return int.Parse(accountProperties["expires_in"]);
    	});
    }
    

    I have a pull request open to include this method out-of-the-box, but until then, we’ll just need to code it ourselves. Finally, we just need to call our refresh token as need be before making an API call:

    var account = AccountStore.Create().FindAccountsForService("MyService").FirstOrDefault();
    
    if (account != null) {
        var token = account.Properties["refresh_token"];
        var expiresIn = await authenticator.RequestRefreshTokenAsync(token);
        UserPreferences["tokenExpiration"] = DateTime.Now.AddSeconds(expiresIn);
    }

    In practice, we’d likely wrap up this behavior around every call to our backend API, checking the expiration date of the token and refreshing as needed. In our app, we just a simple decorator pattern around an API gateway interface, so that refreshing our token was as seamless as possible to the end user.

    In your apps, the URL will likely be different in format, but the basic format is the same. With persistent refresh tokens, users of our mobile application log in only once, and the token refreshes as needed. Very easy with Xamarin and the Xamarin.Auth component!

    Some minor complaints with the component, however. First, it’s not a Xamarin.Forms component, so all the code around managing accounts and displaying the UI had to be in our platform-specific projects. Second, there’s no support for Windows Phone, even though there are issues and pull requests to fill in the behavior. Otherwise, it’s a great component that makes it simple to add robust authentication through your own OAuth provider or piggybacking on a 3rd party provider.

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

    Categories: Blogs

    How do you know that your product works? Slides from my LKCE14 keynote.

    Henrik Kniberg's blog - Wed, 11/12/2014 - 21:44

    Here are the slides for my keynote How do you know that your product works at Lean Kanban Central Europe, Hamburg.

    I travelled with Emma (6 yrs), she’s been wanting to travel with me (alone, without her 3 siblings…) for a long time, so she’s really happy! Thanks Mary & Tom Poppendieck for being her bonus grandparents during the whole trip :)

    Some sample slides & pics below.

    LKCE14

    LKCE14

    How are you improving people's lives

    What you measure is what you get

    Don't rely ONLY on hard data 

    How do you know that your product works

    Categories: Blogs

    Agile Through a Matrix Lens

    Tyner Blain - Scott Sehlhorst - Wed, 11/12/2014 - 21:39

     

    glasses lens

    “Agile” is something most teams do wrong*, without realizing they’re doing it wrong.  A good 2×2 matrix acts as a lens, helping to convert information into insight.  Let’s apply this lens to agile as applied within a company, and see if it helps people decide to do things differently.

    When You Say Agile, What Do You Mean?

    There may be as many definitions of agile as there are teams practicing agile development.  Generally, people are talking about iterating in what they do.  Instead of having a long, throw it over the wall process, out of which emerges a deliverable; a team will have a series of shorter iterations where they engage stakeholders and otherwise rethink what they are doing to course-correct and “get smarter” about what they are doing.  The Wikipedia page on agile is pretty comprehensive.

    Most teams think about agility in terms of how their development teams manage their process.  When “going agile” is the only thing you do, your product does not magically become more successful.  Some teams** think about what it means to be agile when determining what the development team should be doing in the first place. My epiphany was in realizing that these are two separate decisions an organization can make.

    A 2×2 Matrix of Agile

    When an organization can make two discrete decisions about being agile in how they create products, it results in four possible outcomes.  A 2×2 matrix can act as a powerful lens for exploring these decisions.  Our first step is to define our two axes.

    Requirements – how are they treated within the organization / by the team?

    • Requirements and expectations are immutable – this is the typical expectation within a large bureaucracy; someone built a business case, got funding, and allocated a team to deliver the product as-defined.
    • Requirements continually revisited – this is what we see nimble teams doing – at different levels of granularity, context, and relevance; at a low level, this is A|B testing and at a high level this is a pivot.

    Development process cadence – how frequently does the team deliver***?

    • Infrequent delivery – there is no one size fits all measure to define infrequent vs. frequent; some companies will have fast-moving competitors, customers with rapidly evolving expectations, and significant influence from evolving technology – others will not (for now).
    • Frequent delivery – the precise delineation from infrequent to frequent delivery is contextually dependent.

    With these two axes, we can draw a matrix.

    Agile 2x2 Matrix

    A subordinate message that I couldn’t resist putting into the matrix is that it is harder to do your job in an agile way.  I think you could pedantically argue that agile is easier – by saying it is easier to deliver the equivalent results when your process is agile.  And that’s true.  The point is to deliver a more successful product, which is harder than delivering a less successful product.  An agile approach makes that task easier.  Maybe another way to think about it – if your team is not capable of delivering a good product, going agile will make that more obvious, faster.

    Living in Boxes

    Everyone can map their team into one of the four boxes.  That’s the power of this sort of abstraction.

    Here’s where I can use your help: What are better names for these boxes?  I have satisficed with these names, but they could be better.  Please comment below with proposed alternatives, because I’ll be incorporating this lens into other aspects of my work, and I want it to be better than it currently is.

    Waterfall as Practiced

    barrel

    While there are some teams which consciously choose agile because of the planning benefits or perceived risks to quality, I believe that most waterfall teams are still waterfall either because they haven’t chosen to revisit their process choices, or they tried and failed.  Perhaps their instructors weren’t good, perhaps the team was not equipped to make the shift.  My guess is that their organizations were unwilling or unable to support any change in the bureaucratic status quo, effectively making it impossible for the teams to succeed.

    BUFD & BUFR (Buffed and Buffer)

    set in stone

    BUFR is an acronym for big up-front requirements, and BUFD is the equivalent for big up-front design.  Both of them are labels assigned as part of the decade-old war between interaction design and extreme programming.  Conceptually, the battle is between rationalists and empiricists.  In a nutshell, the requirements are Defined (capital Defined), then the team applies an agile development methodology (mostly) to incrementally build the product according to the requirements.

    This is another area where can explore more – what are requirements, what is design, who owns what? My main point is that the developers, while going through the agile motions – even when getting feedback – are only realizing some of the benefits of agile.  Yes, they can improve the effectiveness of their particular design or implementation at solving the intended problem.  Yes, they can avoid the death-march.

    The problem is that the requirements are set in stone metaphorically.

    At the end of the day, the team is empowered to rapidly iterate on, and change how they choose to solve the target (market) problems.  The team is not empowered to rapidly change their minds about which market problems to target.

    When agile is being introduced to a larger organization, as a grass-roots initiative starting with a development team, this is corner the team will find themselves in.

    Req’s Churn or Glacial Dev

    bingo ballsglacier

    I struggle for the right way to describe the situation where the people responsible for determining the requirements are getting market feedback and changing their requirements, which the people responsible for creating the product are unwilling or unable to accept changes from the initial plan.

    From the development team’s point of view, “the product manager can’t make up his mind – we are just churning, without getting anything done!”

    From the product manager’s point of view, “the development team is too slow, or intransigent, and can’t seem to keep up.”

    There’s only one environment where this approach is somewhat rational – outsourced development with limited trust.  When the relationship between the product management / design team, and the product creation / test team is defined by the contract, or the two teams do not trust each other, the only reasonable way to make things work is to establish explicit expectations up front, and then deliver to those specifications.  Note that the specifications typically include a change-management process, which facilitates reaching an agreement to change the plan.  The right way to make this type of relationship work is to change it, but if you’re stuck with it – this is your box.

    Agile as Intended

    Yin Yang

    Ah, the magic fourth box. Where rapid delivery leads to rapid learning which leads to rapid changes in the plan.  The success of agile is predicated on the assumption that as we get feedback from the market, we get smarter; as we get smarter, we make better choices about what to do next.

    This is what enables a sustainable competitive advantage, by enabling you to sustainably differentiate your product from competition, rapidly adapt to changing customer expectations and market conditions.  Effectively, you are empowered to change what you choose to do, as well as how you choose to do it.  This is what agile product management is about – enabling business agility.

    A winning strategy involves selecting an attractive market, developing a strategy for how you will compete within that market, then developing a product (or portfolio) roadmap which manifests the strategy, while embodying the vision of the company.  It is possible to do this in any corner of the matrix (except the upper left, in my opinion).  The less willing you are to rely on your ability to predict the future accurately, the more you will want to be in the upper right corner.

    Conclusion

    There isn’t a particularly strong argument against operating your team in the upper right hand corner of the box, Agile as Intended.  The best argument is really just “we aren’t there yet.”  From conversations I’ve had with many team leaders, they seemed to think that getting to the lower right corner was the right definition of “done.”  They thought they were “doing agile” and that there wasn’t anything left to change, organizationally.  And they wondered why their teams weren’t delivering on the promise of agile.  It’s because they weren’t there yet.

    Hopefully this visual will help drive the conversation forward for some of you out there.  Let me know if it helps light bulbs go off.

    Attributions and Clarifications

    Special thanks to Prabhakar Gopalan, who introduced me to The Power of the 2×2 Matrix, a really good book for framing ideas, in his craftsman product management training class.

    *Agile isn’t a noun really something you do, agile is an adverb describing how you do something.  English is a funny language, and “doing agile” is generally used to reflect developing a product in an agile manner.  Sometimes it is important to point this out – particularly when you’re trying to help people focus on the product and not the process (like here), but for this article, I didn’t want to dilute the other messages.  As a bonus, the people who would be tweaked by the use of agile as a noun are generally people who “get it” and I like the idea that they read the whole article, just to see this caveat.  Thanks for reading this :).

    **This is based on anecdata (thanks Prabhakar for the great word), but my impression is that small companies commonly do this – think Lean Start Up – and large companies rarely do this.  I suspect this is more about the challenge of managing expectations and otherwise navigating a bureaucracy built to reward execution against a predetermined plan.

    ***Definitions of “deliver” make for a great devil is in the details discussion too – do you deliver to end-customers or internal stakeholders?  What if your existing customers refuse to update every month?  How many versions of your product do you want in the field?  Another great topic – but not the focus of this article?

    Categories: Blogs

    Agile Projects should have Effect Targets

    Dear Junior

    Measuring projects and setting targets for them is a tricky business. And, it does not get easier when agile projects enter the scene. This is not really because agile projects are strange per se, but because they are different from non-agile projects.

    Setting targets and measuring projects is also an important business. I have seen several agile initiatives fail. Most of them have failed because they did not succeed in setting goals for projects, and monitor their progress. And if you cannot do that, you quickly lose the confidence and support from upper management. Agile initiative terminated, or left to dwindle away. End of story.

    However, it need not to be so. Agile projects can have measurable targets, and they can be monitored - you just have to do it right.

    There are some bad news and some good news.

    The Well-Established Chaos Rod for Measuring Success

    The bad news is that agile projects cannot be measured using the de-facto established standard rod for project success.

    The standard rod for measuring projects is "on-time and on-budget, with all features and functions as initially specified", as used by e g Standish Group in their much-to-cited Chaos Reports. Let us call this the "Chaos rod". Most organisations use some version of the Chaos rod for measuring their projects.

    As we have discussed earlier it is pretty obvious that "all features implemented" is not a good way to measure "project success" - not for any project. Nevertheless, this is the standard rod.

    Damned if you do, damned if you don't

    Of course agile projects will fail if measured using the Chaos rod. The reason is simple - agile projects does not manage to keep their hands away from fiddling with the original specification. Agile projects remove stuff, change stuff, add stuff - agile projects are in a constant state of scope-creep.

    This is no coincidence - it is how agile projects are designed.

    Think of it this way: If we learn something during the run of the project - shall we let that insight effect the plan of what we intended to do? Or shall we ignore that insight, sticking to the original plan even though inferior? Of course we will adapt! Anything else would be ridiculous.

    An agile project anticipates that such insights will emerge, so its processes are designed to harness and leverage upon those insights: demos, retrospectives, re-prioritisation of product backlog etc. These practises are all aimed at constantly refine and redefine the scope. But then, we have derived from the original specification "all features and functions as initially specified".

    Thus, any agile project longer than a sprint will fail - by definition. That is, if you use the Chaos rod for measuring success.

    To put it bluntly, if you measure an agile project using the Chaos rod, it will fail. Either the agile process will fail, or the project as defined will fail.

    Either, the project adapts to its measuring rod and blindly follows the "functions as specified", throwing whatever insight gained aside. Then, "project" will succeed, but "agile" will fail.

    Or,  the project will work according to its agile-minded processes, and then certainly the result of the project will not be "all features and functions as initially specified". Then, "agile" will succeed, but "project" will fail. I e project will fail as measured by Chaos rod.

    Damned if you do, damned if you don't.

    A New (or Old) Hope

    The good news is that the Chaos rod is not the only way to measure projects. As we have discussed earlier, there has always been two ways to measure projects: feature list (Chaos rod) or measuring business effect, what we can call the Effect rod.

    Let us take our earlier example with an on-line book store. They had an idea that recommendations of the type others-have-bought would increase their sales, so they set of some money for that projects.

    Using the Chaos rod they would have created a feature list around others-have-bought recommendations. The project would later be evaluated on how well it implemented the list. But let us look at a better idea.

    Using the Effect rod they might set a target that customers will by 0.35 more books per checkout on average. The Effect rod is used to state the value of a project. These 0.35 books can probably be converted to money, that makes the project worth the effort.

    The project might start out with an idea that others-have-bought recommendations would cut the cake. After the first small stories, deployed to production and put into hands of customers, the team learns that some kind of category would be helpful. To facilitate this they implement a simplified "search similar" as one of their features.

    Suddenly the number of books in the checkout carts raise to a level 0.4 above the pre-project baseline. And the level sustains, it was not just random noise - the change is statistically significant.

    The project has fulfilled its target according to the Effect rod, and is declared a success.

    Measuring using the Chaos rod "on time, budget, and specification" - the project would have been deemed a failure, because it did not deliver the initially specified others-have-bought.

    So, agile projects can be measured. You just have to use a measurement that is well suited. And, to be honest - which is better anyway.

    A sad side-note is that I know of several projects which have worked in an agile manner, and delivered enormous business benefit - but in the project report the project lead has had to apologise repeatedly for not meeting the project target as defined in the project specification - a feature list.

    Granted, to measure projects on business effect is not a new idea in any way at all. The idea was certainly there before the Agile Manifesto was written around the turn-of-millennia. What is new is that this way of measuring is essential to provide rigour to agile projects.

    For Agile to succeed at larger scale, we certainly need lots practises around agile-minded processes. Measuring agile projects on effects is certainly one of them.

    The way to measure agile projects is to set targets for business effect.

    Yours

       Dan

    PS Interesting enough, there is a sub-category "agile projects" in the later Chaos Reports, but the rate of success is not 0%, it is around 40%. I wonder what is going on here.

    PPS Within the agile community, the practice of projects is debated - at least in the sense of the common description "temporary organisation with limited time, resources, and ambition". So, it would probably be better to use some other term, e g talking about "initiatives". However, for convenience, I have kept the often-used and familiar term "project". Check out the twitter hashtag #NoProjects.



    Categories: Blogs

    learning to keep my mouth shut

    Derick Bailey - new ThoughtStream - Wed, 11/12/2014 - 15:00

    I’ve been called “subtle as a freight train at 3am” more than once in my life and career.

    subtle-as-a-freight-train

     

    The truth is, the “Derick Bailey” that you see and read on the internet isn’t the complete me. It’s not that I’m being fake or presenting something that isn’t true. It’s that after countless years of failing, I’ve finally learned that I don’t *need* to say everything that my brain thinks, all the time. Sure, I *can* if I want to. But the freedom to say something does not preclude from the responsibilities and consequences of what I say. So I find it is often better for me and for those that I want to help, if I just keep my mouth shut most of the time.

    On Being Argumentative

    When I was in college, I worked in a sound recording studio. I was responsible for maintaining equipment, cables and more. My boss once asked me to “fix” a cable that I did not think was broken. I argued that it was fine, and he presented evidence to the contrary. Eventually, he got frustrated with me and told me to do it because it’s my job, stating that I should not be so argumentative.  I was mildly taken aback by the accusation of being argumentative, but even then I couldn’t deny it. It made me think a little more the next time I wanted to argue over something petty, with him.

    At another college, I worked in the web development team. My boss was teaching me about database relationships and foreign keys. I understood why the ID from one table should be used in a column of another table, but I didn’t understand why referential integrity was important. My boss blurted out “BECAUSE I TOLD YOU TO!” when I asked him, “Why should I use a foreign key relationship, when I don’t need one?” for probably the 8th or 9th time in as many minutes. Again, I was mildly stunned by the outburst, but couldn’t deny that he was my boss. It made me think a little the next time I wanted to argue over the academics and learning vs getting something done on time, with him.

    On Speaking Before Thinking

    At my first job out of college, I walked in to the I.T. department one day and saw a (former) coworker being walked out the door with a cardboard boxes in tow. I assumed she was moving to a new cubicle or office and exclaimed, “What? Did she get fired or something?!” right in front of the department manager, the person that, yes, had been fired, and the rest of the employees who were now trying to hide their shocked expressions. I can only imagine the look on my face made the department’s collective look of shock pale in comparison, as I instantly realized what I had just said. I immediately walked in to my boss’ office and sat there, alone, waiting for him to show up for the day. He let me stew in my own horror and embarassment for a few minutes, and allowed me the opportunity to explain exactly why my actions and statements were so very very inappropriate.

    Later, at the same job, I was working with a developer from a sibling company. He was walking me through setup of the software that he had built and I couldn’t get it working. I also saw a significant number of flaws in the security model. During a phone call between that developer, the Vice President of the sibling company, myself and my boss, I rather insistently and bluntly stated that the software wouldn’t work and that it was insecure. After nearly yelling at me, right then, the VP of the other company called my boss and yelled at him for 30 minutes. This was one instance where I truely did deserve the ensuing lecture on tact, the reprimand from my boss and the note on my review at the end of the year … deserved and received. This was one instance where it took a number of meetings and mentoring sessions with my boss, for me to understand a more appropriate method and timing for communicating my concerns. The lessons were hard for me, but I believe I came out the other side a better employee and coworker.

    The Struggle Of Introspection

    I’ve spent the last 15+ years dealing with the consequences of my own words and inability or unwillingness to control what I say. It may not seem that way, to those that only see the public side of me on the internet. But anyone that has worked with me directly, will have more than a fair share of stories to tell about me and my mouth.

    Learning to filter my words, both written and spoken, has been one of the greates challenges in my career. It is also likely one of the most important lessons that I am continuing to learn. Most of the time, these days, I am able to delete that horrifying tweet before I hit send… or put off replying to that email until I’ve had a chance to think about how my response will (mis)interpreted. I’m not always successful in my endeavor to refrain from making an ass out of myself. But I have been fortunate in my career and my life, to have friends, family, mentors and even complete strangers at times, that have been willing to put up with me in order to help me become a better, more effective me, with language and communication.

    We All Have Our Blunt, Freight Train Problems …

    because we are all human, and not one of us has a complete understanding of how our words will be interpreted by those with whom we are communicating. It’s part of our nature to assume that our words and statements will be understood as we understand them… how else could they possibly be (mis)understood, after all?

    It turns out, the experience and perspectives that we have shape our own understanding of words the same way that the experience and perspectives of others, shapes their understanding. And while we cannot ever be truly, 100% perfect in communication and expressing ideas so that everyone will always understand the point, we can at least work toward empathy in our actions and words… working toward a style of communication that at least attempts to understand the perspectives of the audience, even though we will never have the complete picture.

    “Between stimulus and response, there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.”  –  Viktor E. Frankl

    - Derick

    Categories: Blogs

    Synchronitis – eine unheilbare Krankheit?

    Scrum 4 You - Wed, 11/12/2014 - 08:30

    Ein Problem, das uns immer wieder begegnet, ist die Tendenz, mehrere Dinge zugleich zu machen. Man beginnt mit einer Sache und während man diese zu beenden versucht, wird einem der hohe Zeitdruck bewusst. Also beginnt man gleich mit der zweiten Sache.

    Die dahinterstehende Logik ist eher nicht vorhanden, es scheint vielmehr eine natürliche Stressreaktion zu sein. Und seien wir mal ehrlich: Wer kennt sie nicht, die ellenlangen To-Do-Listen, und plötzlich schweift man vom aktuellen Thema ab, um mit dem nächsten zu beginnen. Dabei scheint man das erste Thema völlig zu vergessen und wenn es einem dann leider doch wieder einfällt, muss man plötzlich zwei Dinge parallel fertigstellen. Ist ja an sich kein Problem. In den letzten Jahren wurde uns viel über Multitasking erzählt und dass viele Menschen dazu fähig seien. Prinzipiell stimme ich dem zu. Multitasking ist möglich, man kann sich um zwei Dinge gleichzeitig kümmern. Man kann sich nur nicht so gut und gleich schnell um zwei Dinge kümmern wie um eines.

    Wenn Sie glauben, zu den absoluten Ausnahmen zu gehören, dann empfehle ich den folgenden Test. Dafür brauchen Sie eine Stoppuhr, ein Blatt Papier, einen Stift und ca. 2- 3 Minuten Zeit.

    • Single-Task-Variante: Starten Sie die Stoppuhr und schreiben Sie die Zahlen von 1 – 26 durchgehend in eine Zeile, direkt anschließend das Alphabet von A-Z. Stoppen Sie die Uhr (und wenn Sie noch mehr über die Auswirkungen von Single-Tasking versus Multitasking lernen wollen, halten Sie auch kurz fest, wie sehr es Sie subjektiv angestrengt hat).
    • Multitasking-Variante: Starten Sie wieder die Stoppuhr, aber dieses Mal schreiben Sie abwechselnd eine Zahl und einen Buchstaben, also: 1 A B 2 C 3 usw. Stoppen Sie wieder Ihre Zeit (und notieren Sie, wie angestrengt Sie sich gefühlt haben).

    Mein Ergebnis bei diesem Test war recht eindrucksvoll: Beim Multitasking war meine Leistung um ca. 25% schlechter. Außerdem fand ich die Multitasking-Variante wesentlich anstrengender als das Single-Tasking.
    Ich empfehle, es wirklich auszuprobieren. Es kostet nicht viel Zeit und wird Sie hoffentlich von Synchronitis befreien. Es funktioniert einfach nicht, mehrere Aufgaben gleichzeitig gleich gut abzuschließen. Aber es funktioniert wunderbar, eine Aufgabe nach der anderen zu bewältigen – und es geht sogar schneller. Bei der Übung handelt es sich noch dazu um gut trainierte Aufgaben, die jeder von uns schon tausende Male ausgeführt hat. Je komplexer die Aufgaben sind, desto größer wird aber der Zeit- und Qualitätsverlust durch Multitasking, da wir uns in jede Aufgabe wieder neu eindenken müssen.

    In diesem Sinne: Achten Sie auch bei Ihren Scrum-Teams darauf, dass Stories nach Möglichkeit einzeln abgearbeitet werden, statt parallel. Das Ergebnis wird dem Single-Tasking qualitativ und quantitativ recht geben.

    mathematics-111423_1280

    Categories: Blogs

    XP Days Ukraine, Kiev, Ukraine, December 5-6 2014

    Scrum Expert - Tue, 11/11/2014 - 20:03
    XP Days Ukraine is a two-day conference dedicated to Agile engineering practices. Its aim is to provide practical skills and new ideas to Agile practitioners with the help of local and international Agile and Scrum experts. The presentations cover the main Agile engineering practices like TDD, Continuous Integration or BDD. Topics like Agile architecture, technical debt or communication between developers and testers are also discussed. In the agenda of XP Days Ukraine you can find topics like “Design and architecture in Agile project”, “Why testing take so much time?”, “Continuous Development ...
    Categories: Communities

    User Stories Splitting Patterns

    Scrum Expert - Tue, 11/11/2014 - 19:54
    When a Scrum team starts its sprint, it needs to have user stories with the right size so that they can be completely developed at the end of the iteration. The art of slicing larger stories and epics that exists in the backlog to right-sized item for a sprint is not easy. Richard Lawrence has done some work on this topic and has outlined 9 patterns for splitting user stories. He has produced a cheat sheet with example stories for each pattern. These patterns have also been summarized on a poster ...
    Categories: Communities

    Dealing with the linker in Xamarin apps

    Jimmy Bogard - Tue, 11/11/2014 - 18:51

    The last few months I’ve been working quite a bit with Xamarin and in particular Xamarin.Forms. I’ve got a series of posts upcoming on my exploits with that and migrating to ReactiveUI, but first things first, I actually need to deploy my app.

    I’ve got my app working in debug/release mode in the simulator, and debug mode on a device. However, when I ran the app in release mode on a device, it just crashed without warning. Not a very good experience. I’ve deployed this app several times on the device, but something was causing this crash.

    Typically a crash on a deployment is one of two things:

    • Something off in DEBUG conditional code/config
    • Something off in DEBUG/RELEASE project config

    I checked the DEBUG conditional code config, which does things like point to the test/production API endpoints. That looked OK, so what else was different?

    Screen Shot 2014-11-11 at 9.20.41 AM

    That was my debug version of the app, where no assemblies were linked. In the Release mode, only SDK assemblies were linked. For many cases, this works, as the compiler can figure out exactly what methods/fields etc. are being referenced.

    Normally, this is OK, until you get a series of telling exceptions, usually a MissingMethodException. In my case, I switched my Debug settings to the same as Release, and got:

    System.MissingMethodException: Default constructor not found for type System.ComponentModel.ReferenceConverter
      at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00094] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Activator.cs:326
      at System.Activator.CreateInstance (System.Type type) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Activator.cs:222
      at System.ComponentModel.TypeDescriptor.GetConverter (System.Type type) [0x0009f] in ///Library/Frameworks/Xamarin.iOS.framework/Versions/8.4.0.16/src/mono/mcs/class/System/System.ComponentModel/TypeDescriptor.cs:437
      at ReactiveUI.ComponentModelTypeConverter.<typeConverterCache>m__0 (System.Tuple`2 types, System.Object _) [0x0002d] in /Users/paul/code/reactiveui/ReactiveUI/ReactiveUI/Platform/ComponentModelTypeConverter.cs:24
      at Splat.MemoizingMRUCache`2[System.Tuple`2[System.Type,System.Type],System.ComponentModel.TypeConverter].Get (System.Tuple`2 key, System.Object context) [0x00000] in <filename unknown>:0
      at Splat.MemoizingMRUCache`2[System.Tuple`2[System.Type,System.Type],System.ComponentModel.TypeConverter].Get (System.Tuple`2 key) [0x00000] in <filename unknown>:0
      at ReactiveUI.ComponentModelTypeConverter.GetAffinityForObjects (System.Type fromType, System.Type toType) [0x00000] in /Users/paul/code/reactiveui/ReactiveUI/ReactiveUI/Platform/ComponentModelTypeConverter.cs:30
      at ReactiveUI.PropertyBinderImplementation+<typeConverterCache>c__AnonStorey5.<>m__0 (System.Tuple`2 acc, IBindingTypeConverter x) [0x00000] in /Users/paul/code/reactiveui/ReactiveUI/ReactiveUI/PropertyBinding.cs:1006
      at System.Linq.Enumerable.Aggregate[IBindingTypeConverter,Tuple`2] (IEnumerable`1 source, System.Tuple`2 seed, System.Func`3 func) [0x00000] in <filename unknown>:0
    

    First lesson: keep linker settings the same between build configurations. When you encounter this sort of issue, the problem is usually the same – reflection/dynamic loading of assemblies means the linker can’t see that you’re going to access some type or member until runtime. The fix is relatively simple – force a reference to the types/members in question.

    In my iOS project, I have a file called “LinkerPleaseInclude.cs”, and in it, I include all types/members referenced:

    public class LinkerPleaseInclude
    {
        public void Include()
        {
            var x = new System.ComponentModel.ReferenceConverter (typeof(void));
        }
    }
    

    Completely silly, but this reference allowed my app to run with the linker in play. More info on the linker can be found on the Xamarin documentation.

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

    Categories: Blogs

    SonarQube 4.5 in Screenshots

    Sonar - Tue, 11/11/2014 - 18:18

    The team is proud to announce the release of SonarQube 4.5, which includes many new features:

    • Computation of the SQALE Rating and the Technical Debt Ratio
    • Improvement to the Rules pages
    • Redesign of the Treemap

    Computation of the SQALE Rating and Technical Debt ratio

    With this version of the SonarQube platform, the SQALE Rating (letter grade) and Technical Debt Ratio move from the SQALE plugin into core. Now there’s an easy index for project comparison, and an easy way to see it too, the new “Technical Debt Synopsis” widget:

    Improvement the the Rules pages

    This version of the platform brings several improvements to the Rules space.

    The first is the addition of a new Active Severity feature, which lets you search for rules by the severities they have in a given profile (rather than by default severity):

    This version also makes the rule’s SQALE/Technical Debt remediation function visible. I.e. you can see now how much violating a rule will “cost” you in terms of technical debt. Just click on the SQALE characteristic to see it:

    The ability to create new manual rules has also been added to the Rules space. Since markdown is now supported in rule descriptions, you can use it to add some formatting to manual rules:

    Once created, you’ll find them in the “Manual Rules” repository:

    Redesign of the Treemap

    The treemap, one of the earliest visualizations of code in SonarQube got a complete overhaul in this version. Rewritten in JavaScript, you should find it more responsive, more intuitive, and just as beautiful as ever. Among the changes are a better mouseover, and a clickable breadcrumb trail at the bottom for zooming out:

    That’s all, Folks!

    Time now to download the new version and try it out. But don’t forget to read the installation or upgrade guide.

    Categories: Open Source

    How Leaders are Building Digital Skills

    J.D. Meier's Blog - Tue, 11/11/2014 - 17:51

    Cloud, mobile, social, and big data are changing the game of business.

    But to play the game well, leaders need to grow new skills.

    In order to create new customer experiences and market-leading operational capabilities, leaders need to invest in digital skills.

    Our Cloud-First, Mobile-First world provides unprecedented possibilities in terms of connectivity and compute resources for changing customer experiences, transforming the workforce, and transforming operations, and creating new business models.   Companies every day are building amazing solutions that integrate Cloud, Mobile, Social, and Big Data capabilities as well as what the Internet of Things brings to the table.   But to take advantage of these capabilities, you need leaders that grow and invest in a digital platform and in digital skills.

    In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share how top leaders grow their digital skills.

    Creating Great Customer Experiences Requires New Skills and New Ways of Working

    Whether you want to reimagine your customer experience, or reimagine your operations, it takes new skills, and new ways of working.   Companies that don’t have the right digital skills struggle.   Worse, everybody is competing for the same skills, including social media analysts, mobile marketers, cloud architects, and data scientists.

    Via Leading Digital:

    “Creating great customer experiences or market-leading operational capabilities is more than technology challenge.  It's also an organizational challenge requiring new skills and new ways of working.  Yet, 77 percent of companies in our first year of research cited missing digital skills as a major hurdle to their digital transformation success. To compound the problem, most companies are chasing after similar skills--social media analysts, mobile marketers, cloud architects, or data scientists, to name a few.”

    How Digital Masters are Building Skills

    If you want to help your company become a Digital Master, or, if you want to be a high-performing leader, you need to invest in digital skills.  

    Via Leading Digital:

    “So what are Digital Masters doing differently when it comes to skills? First, they are investing.  Of the Digital Masters we surveyed, 82 percent are building the digital skills they need to support transformation efforts.  Only 40 perce3nt of nonmasters are doing so.

    Second, Digital Masters are accelerating and creating  a gap.  Our survey research shows that the masters had greater digital skills than nonmasters, reporting 31 percent higher social media skills, 38 percent higher mobile skills, and 19 percent higher analytics skills.

    But Digital Masters did not start with higher skills.  Burberry did not become excellent at digital marketing. and channels overnight.  CEO Ahrendts hired a new, dynamic marketing team whose members mirrored the behaviors of the millennial customer.  Nor did Caesars excel at delivering personalized customer experience solely because its CEO, Gary Loveman, has a PhD in economics from MIT. Caesars' executives actively incorporated quantitative skills into the marketing area.  In these companies, like other Digital Masters, top executives worked hard to build the digital skills they needed.”

    The Line Between Technical Skills and Leadership Skills is Blurring Fast

    The gap is huge but the lines blur fast.  There is a huge demand for people that are both business savvy and technology savvy.

    Via Leading Digital:

    “The skills difference extends beyond technology.  Digital Masters report 36 percent higher skills in digital leadership than nonmasters. Digital transformation requires changes to processes and thinking--changes that span your internal organizational silos.  'The clear delineation between technical skills and leadership skills in blurring fast.

    The impact of digital technologies is now felt not only in the IT and technical departments, but also across the entire organization.  Digital transformation's need for cross-functional collaboration creates a huge demand for hybrid digital skills-- technical people who need to be more business savvy and businesspeople who need to be more technology savvy.  A retail executive explained: 'We are trying for the first time to work across the company.  That implies going through a new level of complexity in the organization, and requires people to manage and network differently.  That, I think, is the most important skills that needs to be developed.'”

    Successful Leaders Will Have Business and Technical Skills

    True hybrid professionals will be the leaders of tomorrow.

    Via Leading Digital:

    “The need for new skills can also result from the need to bridge the communication gap between digital and business competences.  One executive said, 'I need a charismatic quant--somebody who's an influencer and can carry his weight in a senior meeting, but at the same time, someone who can roll up his sleeves and look at data tables and build models and enjoy it.'

    These bridging roles may soon become the responsibility of every manager. 'I believe,' said Markus Nordlin, CIO of Zurich Insurance, 'that the successful leaders of tomorrow, in any business or industry, are going to be true hybrid professionals who have spent some time in IT but have shifted to operations and vice-versa.'”

    Digital Skills Create Competitive Advantage and Enable Digital Transformation

    To keep up and get ahead, you need to master Digital Skills and be able to use them in a business savvy way.

    Via Leading Digital:

    “Aspiring Digital Masters are all chasing the same technical skills.  The shortage of digital skills is unprecedented.  In Europe alone, forecasts point to nearly a million vacancies for IT-related roles by 2015.  And globally, out of the 4.4 million big-data jobs to be created by 2015, only a third will be filled.

    But by the same token, business professionals will increasingly need to be comfortable with digital tools and technologies to perform their core roles.  By 2015, research firm IDC expects that 90 percent of all jobs will require IT skills.  Some business functions are already adding technology skills to their mix.  Gartner reports that 70 percent of the companies they surveyed have a chief marketing technologist to support the digitization of the function.

    This skills race won't slow down anytime soon.  Having the right digital skills is an important source of competitive advantage and a key enabler of digital transformation.  Companies that build skills faster will get ahead.

    To win at the digital skills race, you will need to tap into multiple approaches--hiring, partnering, incubating, and the like.  It's not easy, as one executive explained: 'Our recruiters don't know where to go to find these people, and people with the right skills don't look to our kind of company for opportunities.'  HR organization will need to get up to speed quickly.  A recent Capgemini Consulting survey found that only 30 percent of HR functions were actively involved in digital skills development.  This needs to change.  Many Digital Masters have a carefully crafted plan to fight and win the talent race.”

    All of the capabilities of Cloud, Mobile, Social, and Big Data are right at your fingertips.

    Using these capabilities in meaningful ways takes a combination of business and technical skills, as well as great organizational change leadership skills.

    If you can master business skills and combine them with great technical skills, you can lead you, your team, your organization, and others to change the world.

    You Might Also Like

    10 High-Value Activities in the Enterprise

    Cloud Changes the Game from Deployment to Adoption

    Drive Business Transformation by Reenvisioning Operations

    Drive Business Transformation by Reenvisioning Your Customer Experience

    Dual-Speed IT Drives Business Transformation and Improves IT-Business Relationships

    How To Improve the IT-Business Relationship

    Management Innovation is at the Top of the Innovation Stack

    Categories: Blogs

    The neverending waveform of the full-stack developer

    Xebia Blog - Tue, 11/11/2014 - 17:50

    There was an article on Techcrunch a couple days ago which was linked in our internal mailing list the other day, titled The Rise And Fall Of The Full Stack Developer. I read it, and I just couldn't figure out why the title is about "the fall" of the full-stack developer (and I said as much on the mailing list, after which I was encouraged to write this blog post). In this post I'll try and explain why it's not the end, but just a stage in a recurring cycle

    What I read was a waveform - the article describes that first you had low-level assembly, which is specialised but still pretty straightforward since it's just one platform and language. Then things started to get more complicated, with the larger web applications involving lots of experts in various fields (Java, database management, server and JVM management, to name a few from the article).

    In or around 2005, there was a bit of a revolution going on. Internet access (and high-speed internet for that matter) became accessible to all, and with it, cheap webhosting - most notably, there was a boom in PHP development. What the article highlights is that that was an era where single or small teams of developers could build a web application from scratch, without needing to lug around all of that expert knowledge - effectively, a full-stack developer (storage, webhosting, a programming language (PHP, Python, Ruby, etc), HTML, CSS, Javascript, the whole stack).

    But, as the article states, that isn't the full stack of today - added to that are things like machine learning, mobile development, more advanced and less traditional programming languages, frameworks and persistence solutions, etcetera. The conclusion of the author is that it's too much for one full-stack developer to take, that there's no way a full-stack developer can be an expert in all of those fields - and he basically renames the person that knows a bit of all of those technologies a full-stack integrator, and declares the full-stack developer dead.

    But I didn't see that. What I saw was just history repeating - from simple and manageable, to complex and too much for one person to handle and know all about. From assembly and PHP, to Java enterprise software and Docker-contained AWS instances running a MongoDB and Scala REST interface to power your Android, iOS and single-page AngularJS-powered webapps (to name but a few buzzwords).

    I'm sure the next 'simple' wave is already around the corner - maybe it's already here, lurking somewhere until some more influential guy goes "Hey guys, let's go back to the simpler, good old times where you wrote code and it Just Worked™!", where a wave of developer will follow - most likely a combination of younger people, new to the software development world, and older people that have been stuck in an overly complicated software development rut for far too long.

    As for not being able to keep up with it all, this is why it's probably better to assemble teams out of T-shaped developers - full-stack developers with a broad knowledge set (and more importantly, broad interests and curiosity), but with at least one specialisation. This was extended within Xebia to pi-shaped developers, then made extreme to comb-shaped developers, but the latter is just a generalist like mentioned in the article - a jack of all trades, master of none. And it's important to realise, as a developer, that it's OK to not know everything, to miss some update, to not learn that fancy new programming language by people disgruntled by Java's slow development - there's simply too much information updates today, and trying to manage it all in the extremest forms can lead to serious problems. But the rapid development is a good thing, I might add, I don't think the software development world has ever moved as fast as it does today, and it's not nearly the end yet as long as more than half of the world's population doesn't have access to the internet and its boundless resources.

    I think increasing complexity is just part of software development. I mean look at Facebook and Twitter - they were started using those simple, accessible tools like PHP and Ruby on Rails, which allowed them to get a flying start and adapt quickly to their huge growth (and with the former desperately clinging to their decision, despite lots of people telling them they should use a different technology), but despite that they still turned into some of the most complicated pieces of software ever. The important bit is to be able to manage all that, not so much a decision between a simple or complicated toolset - or having all of your developers know everything. Similarly, the current trend is microservices - again back to simple, one-purpose miniature applications that do one thing and do them right. But those will just end up being the next generation of huge, complicated software systems, given enough time. As a colleague stated, "Microservices are just hipster SOA".

    As the saying goes, the more things change, the more they stay the same. The full-stack developer isn't dead and won't be going away any time soon, he'll just go by a different name depending on the times - J2EE Certified Software Engineer, full-stack developer, multidisciplinary expert, T-shaped developer, Xebian, chief of technology evangelisation, or whatever else the HR or marketing departments of the near future will come up with.

    Categories: Companies

    Knowledge Sharing


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