Sean Kenefick
Research Director
1 year at Gartner
20 years IT industry
Sean Kenefick (@seankenefick on Twitter) covers many aspects of application platform strategies, including the software development life cycle (SDLC), build and version control tools, and open-source platform and software solutions...Read Full Bio
by Sean Kenefick | February 6, 2012 | Submit a Comment
My research concerning the need for strong SDLC infrastructure has been released. Check it out here!
Here’s a summary:
Every organization that creates software must ensure that the infrastructure supporting its development process is robust and applicable to the needs of the team. In this guidance document, Research Director Sean Kenefick assists you in assessing and updating your software development life cycle (SDLC) infrastructure to match the needs of modern development teams.
Category: SDLC Tags:
by Sean Kenefick | January 27, 2012 | Submit a Comment
I just read Mike Cohn’s interesting article about rotating the ScrumMaster role… As he states (and I agree) that the role is too pivotal to rotate permanently, it might be an interesting way for developers to see what the job entails and to limit the “management” feeling that can end up developing.
It’s an interesting perspective and one I’ve talked about with clients in a slightly different capacity.
As we’re probably all aware, waterfall development relies on functional teams working at different times, often in their own silos. Agile attempts to break down some of these silos and help the team embrace a more collaborative multi-functional environment . That cultural change can be pretty daunting — often times, the roles have seen each other as “the enemy” for years. Breaking down the walls — while to everyone’s benefit — rarely happens overnight.
Enter the “exchange program.” When clients tell me that they’re interesting in trying out agile or DevOps, I often recommend that they first create an exchange program where the different roles try the others out for a couple of days, both to understand the challenges the other roles face and to get better acquainted with the people in the group. For instance, infrastructure folks may sit in with developers, watch them collaborate, see why they choose technologies. Developers may become testers or work with the operational folks to maintain and manage releases for production systems. Business analysts might try out testing. Just for a while.
It’s hard to resent someone you respect. It’s hard to throw inadequate code over the wall to people you like. It makes you think about the tedious processes you enforce when you see your friends unhappily fulfill them. Each functional group member may not have the same skills, but it’s still helpful just to sit and see how the proverbial sausage gets made.
If the teams end up mutating into agile, great! You’ve had a head start. If not, your folks have gotten to know each other and perhaps you can keep that good will going. Sure, it can’t happen all at once — but perhaps team members do a two day exchange once or twice a year. Obviously, this gets a lot more difficult — and all the more helpful — when functional teams are split across towns, continents or the world.
Category: Agile DevOps Tags:
by Sean Kenefick | January 23, 2012 | 1 Comment
Forecasting is hard. Even the best of forecasters don’t get it right very often — yeah, I’m talking to you, Nostrodomus. Yet, in most development models, developers are consistently being asked to forecast. In many cases, developers just end up guesstimating because they don’t have useful historical data they can rely on. Sometimes, that type of forecasting works out. Let’s face it, if I make enough assertions, every now and again I’m going to be right, right? (Especially if I pad my estimates.) But in many cases, forecasting turns out to be a huge failure.
So why are some teams better at forecasting than others? The discussions I have with clients tell me that it’s the way different teams accumulate historical data. Some teams break down and manage requirements using small, discrete tasks. Once they get enough of those puppies out of the pipeline, they start referring to them when forecasting how long something new might take to do.
As an example, image a requirement called “Create customer records screen” that ended up taking you three weeks to write. Now let’s say you broke up that requirement into smaller tasks and created a child task called “Iterate and display customer records” which ended up taking four hours. A year from now, when you’re given a requirement to “Create administration screen,” you can’t really use your history from the first requirement and simply apply it to the second — the screens are likely to be radically different. On the other hand, if the second requirement had a more granular task called “Iterate and display users” — well, using your historical record of four hours might be right on the money.
But remember, breaking down tasks has its down sides too. First, you have to do it. And in a Waterfall world where you’re trying to do everything up front, it can be a huge (but necessary) pain. In an agile world, sometimes focusing too much on small tasks leads people to become resistant to change and causes scrums to become mini-waterfalls. In either case, infrastructure must be in place that allows people to easily research task historical data.
If you want to be able to forecast, you have to shrink your history. The trick is to find your task size happy place and then be able to exploit its metadata later when you need it.
Category: Agile Issue Mgmt Tags:
by Sean Kenefick | December 22, 2011 | 1 Comment
First off, very happy holidays to you and yours.
My update to the SDLC Reference Architecture documents were published a couple of days ago on Gartner.com. Additionally, stay tuned for details concerning the release of my SDLC guidance document entitled “Increasing Agility Through Software Development Life Cycle Infrastructure,” to be published during the first quarter. That’s in addition to the ALM market profile I mentioned in my last post.
For those unfamiliar with Gartner’s GTP Reference Architecture document set, you can find out more about it here.
Click here to navigate to Gartner.com to view the SDLC Reference Architecture overview document. You can navigate to the other documents via the overview. This set of documents describes the basic functionality and use cases for the SDLC disciplines listed in the graphic below. One notable exception — the Environment Configuration Management document is not yet available and will publish some time in the first half of next year.
Category: ALM Build CI SCM SDLC Tags:
by Sean Kenefick | December 20, 2011 | Comments Off
All of the application lifecycle management (ALM) tools promise aspects of visibility and transparency. Those two words are often used synonymously — but isn’t there really a difference between them?
Something can be visible but remain undetected, hidden in plain sight. As an example, someone involved in a court case might try to thwart an opponent by ensuring that important discovery material is obscured by a sheer mass of irrelevant paperwork. It’s all visible — but it’s not meaningful.
Transparency is the means of pinpointing the needle in the haystack, taking something that appears opaque due to its scope or other properties — a huge mass of unrelated data, for example — and presenting the information to users based upon a relative importance.
And that’s the big difference between the terms “visibility” and “transparency”. Different roles in the SDLC require varied sets of information — and it’s the transparency, much more than the visibility, of data that makes it truly valuable. As a quick example, transparency is an absolute necessity when empowering agile teams. Otherwise, how could anyone ever hold the team accountable?
Transparency is a key necessary feature of ALM tools… you can read more about it and them in my upcoming ALM market profile (planned publish date in early Q1).
Category: ALM Agile SDLC Tags:
by Sean Kenefick | December 13, 2011 | Comments Off
Since I re-booted my blogging life on Gartner’s Blogging Network, some folks have asked me to publish links to my existing research. So here you go!
This document discusses the new generation of version control tools such as Git and Mercurial.
This document focuses on the findings from our contextual research findings on application software development.
This document is an assessment of agile development methodologies and can act as a primer for those wishing to learn more about this more productive way to create software.
DevOps is an extension of agile methodologies and focuses on how release management plays a part in application development.
Category: Agile Build CI DevOps SCM SDLC Tags:
by Sean Kenefick | December 8, 2011 | Comments Off
After a year with Gartner, I’ve decided it’s time to start blogging again. It’s been a while — I’ve mostly kept to myself and Gartner clients and the occasional tweet — but my production schedule here at Gartner (typically two research papers a quarter) doesn’t always allow me the ability to speak about everything I’d like, so I’ll try to use the Gartner Blog Network to facilitate those conversations.
About me: I’m a GTP (Gartner for Technical Practitioners) analyst focusing on application development. My areas of expertise include the software development life cycle (SDLC) infrastructure and methodologies such as agile and DevOps. In upcoming posts, I’ll be discussing these topics and more in this space. Some of the topics I anticipate covering in the next few weeks include test environment parity, open source testing tools, and some of the impressions I’ve got on the ALM vendors who briefed me as part of my upcoming research.
Nice-to-meetcha.
Category: Uncategorized Tags:
