Dashboards, Transparency and Strategy

I recently started writing an article on Using Scrum Methods with IBM DevOps Services (IDS), I mentioned that I would follow up with some other topics of interest to users of IDS, like dashboards.  As I began to write that article, I could feel a series of more general observations coming out.  There are some things that I have noticed about the general use of dashboards that I have seen, and how this fits with the strategies and transparency of the organizations that I work with.  This article will talk a little bit about the observations that I have made, and some of the important general concepts to keep in mind.

Now I have seen the things that I mention here done with Jazz dashboards, or dashboards in IDS.  I have also seen it with similar dashboarding capabilities in other products.  I have even seen wiki’s used with some amount of success.  The techniques and observations that I mention here work regardless of technology – so focus on the concepts.

Why Does Everyone Want a Dashboard?

Dashboards are a nice way to see how things are going for your team/project/organization at a glance.  Executives and leaders love them, even when they don’t fully understand them.  I find that dashboards can have a profound impact on teams and organizations when they are used correctly, and can have some negative effects when not used wisely.  Here are some basic and important things that you should remember when you use dashboards:

  • Dashboards should be used for transparency – everyone in your organization should have a common view of how things are going, based on common data.  Individual teams may focus on things within their scope, but they should be able to put their mission and their success (or struggles) into the broader context of the entire organization.  Software people can get blinders on, it’s important to remind them that there are higher business goals that they are contributing to.
  • Transparency is good – Transparency means sharing information, both good and bad.  This helps teams see themselves in a more realistic light, and it pushes teams to perform more efficiently and with higher quality.  Transparency will also help reduce miscommunication and wasted effort within your organization.
  • Strategy is key – Transparency for the sake of transparency is just a lot of noise.  “I had a burger for lunch”, “I’m wearing a green shirt today”, and “I just finished testing some code”, are all logically equivalent statements, when not tied to a strategy.  All of this transparency needs to be focused and tied to a solid strategy.

How Do I Make Transparency Effective?

In order to make transparency effective, you need to consider a few things.  The most important is strategy.  Your transparent communications should be aligned with the strategy of your organization.  In my experience, it is best to have a small list of key organizational objectives.  These can be things like, “Capture 10% of additional market share”, “Increase Revenues by 7%”, or “Improve quality by 10%”.  They key here is that they need to be measurable.  Some people like the so called “Smart Metrics“, which are Specific, Measurable, Attainable, Realistic and Timely (although there are other slightly different Smart Metric definitions).  They are usually a good benchmark for what you want for goals.

This is where some discipline comes in handy.  Defining these types of goals can be difficult, so don’t just spend 5 minutes whipping up some strategic goals that don’t really say anything.  Spend some time, think about it, and come up with some specific goals for your teams.  Your strategy is going to be implemented by these goals, so make sure that they clearly articulate your business strategy.

Once you have these high level goals, you can begin to think about how to reflect them on a dashboard.  We often take 1 or 2 team level metrics for each strategic goal, and measure them over time.  I would say that you should not have more than 3 metrics for each goal reflected in a dashboard, otherwise you tend to dilute the focus of your team.  Do this for each of your strategic goals, and you are all set.

Now let your team know about the dashboard, so they can work to make themselves look good.  Also let the rest of the organization see your dashboard, so they can see how well (or poorly) your team is doing on meeting their goals.  Don’t be afraid of “bad news”, or measures that come up short.  It just highlights areas where you team needs to focus more.  In order to have a high performing team, you need to build a sense of pride and accomplishment, and have meaningful goals – putting team results out for the rest of the organization to see is one way of doing that.  (Note: Read The Wisdom of Teams by Jon R. Katzenbach & Douglas K. Smith – or check this Wisdom of Teams cheat sheet.  This is a must read for anyone leading Agile teams.)

The key here is to focus on the team – and not on individuals within the team.  Your team succeeds or fails as a team, make sure that they all understand this.  Once this attitude is part of your team culture, collaboration within the team will increase, and this will lead to better collaboration with other teams.  A dashboard focused on team metrics and accomplishments that drive towards meaningful goals can help drive that culture.

I Can’t Possibly Manage My Team This Way

At this point, I can hear a lot of people saying, “My team does complex work, and we cannot just run off of a single dashboard showing 1or 2 metrics for each strategic goal”.  Guess what?  I agree.  Most teams do a lot of work supporting activities that do not get reflected in your strategic goals.  Having a dashboard will help you focus on what really is important.  If these things are necessary, you and your team will know it, and continue to do it.  If not – then they will die off (which is a good thing).  Use your dashboard to help your team eliminate work with no value.

You also have other things that you need to track, or other things that you want to track.  These things can go on an internal team dashboard – one that is visible to your team, and one that they pay attention to.  This “internal dashboard” should have all of the same metrics and goals on your team dashboard that you share with the rest of the organization.  However, it will have a few additional things.

TOXTOXTOX

I Can’t Expose Our Strategy, That Would Be Suicide!

Mention Sun Tzu and the Art of War.  Mention US military doctrine in the Gulf War.

Things Change

Mention that dashboards change as the business environment changes.

Using Scrum Methods with IBM DevOps Services

Note: I co-authored this with Patchanee Petprayoon, so you can also find this on her WordPress blog, Ppatchanee.

This article is in response to a number of frequently asked questions about sprint planning and scrum methods, as well as some links to other resources we have created or found to answer those requests.  Before we dive deeper into the topic, let’s take a quick look at what type of scrum work items are provided in IBM DevOps Services. If you have never used any scrum methods before, this can be overwhelming at first.  That’s OK, just read through this and try to digest as much as you can.  If you are familiar with Scrum and Agile methodologies, just skim through all of the explanations to get to the meat on how to do things with IDS.

We call out some sections of this whole process in this indented green text.  These represent best practices, or areas where you can dive more deeply into how IDS works. 

You might also note that a lot of the links for terminology in this article lead to Wikipedia references.  It’s not because we love wikipedia, it’s because too many of the good articles out there have a lot of product references (like this one does – with IDS).  I went looking for some content that was tool agnostic – and Wikipedia is often the best bet for that type of material.

Before We Begin

If you haven’t already registered for IBM DevOps Services (IDS) and Bluemix, you should register now.  It will help you follow along with our examples and will allow you to try a few things for yourself.  You can use IDS alone, use Bluemix without IDS, or use them together.  You may have used the Scrum Process with Rational Team Concert in the past.  If you did, then a lot of this will look quite familiar.

Getting Started with IBM DevOps Services (IDS)

Once you have registered with IDS, you will want to create a project.  To do this, go out to your IDS dashboard.  Click on Create a Project.  You will see a new project dialog come up.  Give your project a name (like “Sample Scrum Project”), something that will identify it.  Then select where your source code repository will be.  For the purposes of this article, it doesn’t really matter, since we’ll just be looking at some common Scrum methods, and will not be dealing with code.  Then make sure that you have a checkmark in the box for “Add features for Scrum development”.  If you are an adventurer, and want to play around with some code, and then deploy it to Bluemix, you might also want to check the box for “Make this a Bluemix project”.  Finally, hit the “Create” button in the lower right, which will create your new scrum project.

So now we have a Scrum project created, and you can see it in the browser.  Now we want to set it up correctly.

In the future, we’ll want to add other members of our team to this project.  To do this, just click on the link for “Members” on the left hand nav bar, and then click on the “Invite Members” icon to add members of your team to the project.

Right now, we just want to learn how to use IDS in conjunction with some common Scrum practices.  One of the first things you’ll need to do is to decide on the length of time of each of you iterations.  In Scrum, these are called Sprints.  Each Sprint represents a period of time where the development team will develop and test code, and commits to have an executable application at the conclusion of the sprint.  That means that you have a running application at the end of each sprint.  It may not expose all of the functionality that has been developed, and some functionality may not be present, but it will execute.

Most scrum teams run with 2 week sprints.  To set up your sprints, start on the overview screen, and press the button labelled “Track & Plan”.  Once on this screen, select “Sprint Planning” from the nav bar on the left.  Since you have just started your project, you don’t have any sprints right now.  So let’s create some.  Click on the “Add Sprints” button in the Sprint Planning window, and add 4 new sprints, and make them 2 weeks in length.

If you click on “Edit Sprints” at this point, you can see how you can now go and add new sprints, rename your sprints, and change the dates on your sprints.  When working with IDS, we suggest naming your Sprints the same as the end date of the sprint.  That way your stakeholders who are unfamiliar with Agile can look and see when their user stories will be implemented at a glance.  They really don’t care about sprints or Agile development, they want to know when they can expect things.

Defining Your Initial Work

Now you have the basic project setup done.  It’s now time to start thinking about doing actual work.  The first thing to understand is the different types of work items available to you to capture your work.

Work Item Type What it is used for
 Story (sometimes called User Story) A user story is a description of some functionality needed, told from the perspective of the end user of the application.  Some people find this equivalent to a use-case.
 Task Tasks are single user tasks used to accomplish some well defined and well scoped effort.  Stories are typically broken down into the multiple tasks, representing the work needed to accomplish the implementation of a Story.
 Epic Epics are stories that are too large to be contained within a single sprint.  Typically an Epic can be broken down into two or more Stories.
 Defect Defects are bugs, problems with the application.  Many Scrum teams will treat them similar to how they treat stories, by decomposing them into the tasks needed to be done to fix a particular defect.
 Impediment These are the risks, issues, and environmental factors that stop work from being accomplished.  Typical impediments may include things like waiting for properly signed SSL certificates, waiting on hardware availability, lack of stakeholder availability, and other similar situations.
 Adoption Item Adoption items indicate when changes made by one team need to be accepted (and integrated) with another team.  An upgrade to a new database version is an example of this.
 Retrospective Retrospectives are held at the end of each sprint, and they allow the team to reflect on what is working well, and what isn’t working well.  It is an attempt to keep the team focused on continuously improving their effectiveness.  Retrospective work items capture the notes and observations made by the team during a retrospective.
 Track Build Item Used to track builds, and relate them to them functionality that they will deliver.  Not a lot of teams use these.

So at this point you should begin creating user stories, epics, impediments, and adoption items for all of the work that you are aware of.  Just click on the “+” in the backlog box to begin creating your first work items.  Once you click on it, just type in a brief headline or general description of the work.  Don’t worry, you will be able to fill in more detail later.  Click on the small icons below the text, to change the work item type, add a more detailed description, and so on.  As you add work items, they will begin to display in your team backlog.

First work item

The edit sprints button, some text for a first work item, and the icons to change the work item attributes

Backlogs are a critical part of scrum development.  Your backlog contains all of the work that your team thinks that it may need to do, but that the team has not yet committed to doing.  If you haven’t scheduled it, and assigned the work to a particular sprint, then it should be in the backlog.  Mature products may have backlogs with 100 or more items in them.  We’ll discuss how to manage your backlog in the next section.

After you have created your initial work items, take a look at your backlog.  It should show all of your work items.  Click on any individual work item, and you will see the details about that work item.  Go back to your sprint planning view, and you will see the work items displayed along with some summary information.

When looking at the details of a work item, it is important to note the fields in the work item.  All of them are self-explanatory, but they do impact how your team does it’s work.  Often lists that are displayed (like your backlog) will have higher priority items at the top.  The discussion field is used to discuss work items, and to provide a running status on the work items. 

When you want to ask someone something in a discussion, click on the link icon with a person, and you will get a dialog where you can choose the specific person that you want to identify.  Now once you save your changes, that person will get an email notifying them that you have asked them a question, along with a link to the workitem.

If you have people always asking about the status of some work, just go to the links tab on a detailed work item, and add that person as a subscriber.  You can add yourself or other people as subscribers to a work item.  whenever a work item is modified, all subscribers get an email that notifies that of the modifications made to the work item, as well as a link to the work item.  We end up using much less email, and having far fewer status meetings, because by using subscribers we are able to keep everyone informed on the progress of critical work items.

Backlog Management

Let’s face it; even though we try our best to estimate things, we’re often very wrong.  We’re not wrong because we are dumb, we’re wrong because we don’t have enough information.  So when using Scrum, we look at each story on our backlog, and we estimate the size/complexity of the story using story points.  Teams will use various methods for estimating story points (some use Planning Poker).  The way that we size the story is very easy and straightforward. If you think that the user story can take a short amount of time to complete, then you give it a low number. If you think it’s going to take a lot of effort to get the user story done, then you give it a high number.  As time goes on, you will get a better feel for estimating work in this way.  You can do all of this work while in that same sprint planning view, capturing your decisions and discussions in the work items as you go along.

There is heated debate about assigning story points to user stories.  Some people think that it is a measure of risk and complexity, some think it is a measure of difficulty, some think of it as a measure of effort.  Do what works for you.  I like Michael Tang’s quick view of story points, but you can find other viewpoints from Mike Cohn and others.  Just spend 30 minutes Googling this and educate yourself.

Once you have estimated the relative sizes of your stories, you are now ready to do some backlog grooming.  In the left hand nav bar, you will notice a link called “Backlog”.  Click on that link, and you should see a nice list of all of your stories.

BacklogGrooming

Backlog Grooming Example

Now we can begin grooming this backlog.  Drag the most important story, the most critical one, to the top of the list.  Now drag the second most important story, and drop it below the first story.  Keep doing this until you have a ranked list of your user stories.

Clicking on a user story will bring up details about it, which you can use when discussing them.  Be careful when dragging and dropping user stories.  If you drop a user story on top of another user story, it will make that user story a child of the user story it was dropped on.  Sometimes you want to do this.  If you didn’t want to do this, then click on the small plus sign “+” on the left of the user story, which will display it’s children.  Then click the small “x” on the left of the child user story, to remove it from being a child.  If you drop it in-between two user stories, it will get ranked between them.

This is your ranked backlog.  This is a critical step for your team, because this indicates the relative priorities of the work that you have been asked to do.  When we get into sprint planning in the next section, you will see how we look at the top of the backlog when planning our next sprint.

Backlog grooming is an important and ongoing activity.  Some scrum teams will do backlog grooming once per sprint, others will do it monthly, and still others will try to do it on an ongoing basis.  The thing to remember is that stories on the backlog need to be reviewed periodically, to ensure that the estimates are accurate, and that the business and development environment have not changed and impacted their priority in relation to other stories on the backlog.

Sprint Planning

Now we get to the key piece of software delivery planning, Sprint Planning.  In your IDS browser, in the left hand nav bar, click on the link called “Sprint Planning”.  When you do this, on the left hand side you will see the ranked list of your backlog items, with the highest raked items on top (I told you that backlog grooming was important!).  On the right hand side you will see an empty list, which represents your first sprint.  Now at this point, you would begin to drag user stories and work items from the backlog (on the left), to your sprint (on the right).  Go ahead and try it.  Move the top ranked user story from the backlog to your sprint.

When you do this, you will notice some changes.  Now in the right hand list, click on the link for “Team Progress”.  What should you see?  Well you should see that the story is now scheduled to be done during the first sprint.  You’ll also notice that the story points assigned to this story show up in the team progress (you now show as having completed 0 out of x story points).  Observant users will also see that the ranked list has updated, and that the next item on the backlog now has a ranking of 1.

Continue to assign stories to your first sprint for what your team can GUARANTEE that they will finish in the timeframe of the first sprint.  That means COMPLETELY FUNCTIONAL software that satisfies the user stories.  Do not over-promise – this is your team’s commitment to complete the work in the timeframe of the first sprint.  Keep in mind that you’ll also have to do testing, and that some bugs may pop up and need to be done as part of the work of this sprint.

The amount of story points that a team can normally complete within a single sprint is called the Team Velocity.  You need to have a gut feel for how much your team can do in your first few sprints, until you get enough history of doing Agile development to understand the velocity of your teams.  Once you have this history, it is easy to assign work to sprints up to three of four sprints in the future, because you have an understanding of how your teams perform.

There is a pile of articles and blogs on Sprint Planning.  What we have seen work the best is when teams commit to doing about 60% of their capacity in a sprint.  This leaves them time for unanticipated surprises, bugs, and other things. It also allows them to build confidence and meet their commitments.

If a team notices that they are half way through their sprint, and that they are almost done, they can then go back to the backlog (or even a future sprint), and pick one or more appropriately sized stories to complete early, in the remaining time that they have in this sprint.  Nobody has ever complained about getting functionality early.

Sprint planning is only half done at this point.  You now have a set of user stories that you are committing to implement in your sprint.  But HOW are you going to do it?  You’re going to have the entire team take those user stories and break them down into the discrete tasks needed to implement those stories.  Look at your sprint backlog now, and on the top story click on the icon for “Open child task breakdown”.  You’ll see that label when you hover over the icon.

SprintPlanning

Sprint planning – creating the tasks for your user story

Once you click on the icon, a new screen appears.  This is your area to enter all of the child tasks for the story that you are breaking down.  You should just click on the plus sign to create a new task work item, that will be a child of the user story that you selected.

TaskEntry_1

Starting your work item entry – use icon to designate this as a task

As you enter in some text to define your new task, you’ll also notice some icons below the text area.  Use the icon on the far left to set the work item type.  In our case, we will want to make this a task.  Notice that this adds some additional “shorthand” to your task description.  Try the other icons, and become familiar with the attributes that you can change in your work item.

At this point you should be getting used to how the work items work within a sprint.  You could easily decompose a large story into smaller stories, making them children of the larger story.  Don’t go crazy with parent-child relationships, use them where it makes sense.  It can be effective to have everyone looking at the same screen during these planning meetings, so the whole team is aware of the tradeoffs discussed, and the whole team has input on the estimates and work breakdown.

Use the icons to set attributes for your work item

Use the icons to set attributes for your work item

Work with your team to define all of the tasks needed for the completion of the user story.  When you are done, you should have a list of tasks that are in the Open column.  Now click on the small down arrows at the bottom of the first task in the list, and you will see some detail information for your task.  You and your team should now look at estimating how much effort each task will take.  You can also further clarify things if you need to.

Adding estimates to your tasks

Adding estimates to your tasks

Go through all of the tasks for this story, and then do the same exercise with your team for the remainder of the stories in your sprint.

At this point you are almost done with your Sprint planning.  You now need to go back and review what you have done, and check your estimated work against the calendar.  Navigate back to your original sprint planning page, and then click on the link for Team Progress.

Checking your sprint estimates

Checking your sprint estimates

You will see that you have an total of the estimates of all of your tasks in hours displayed, a number of work items assigned to the sprint, and a total of the story points.  These are all represented as the second number (0/n) in those progress indicators.  Make sure that you have not overcommitted to the sprint in terms of hours (a two week sprint, means 80 hours of work for each person on the team), or in terms of story points.  Also make sure that you have not undercommitted, and if you have, look for additional stories off of the backlog that you can assign to this sprint.  You’ll spend the remainder of your time in sprint planning making adjustments.

In a lot of the literature on Sprint Planning, they discuss a Sprint Backlog (which is what you are building here), and a Product Backlog (which we just call a Backlog here).  The terminology can be confusing, but in the end the important thing is that you commit to right amount of work for your sprint, and that you correctly define that work for your team.

When do we start doing work?

All of that effort, and we have not written a single line of code.  Ugh!  It can be tough sometimes for people eager to dive in and start prototyping and coding.  Planning is important – it helps us focus on the things that will bring value to our stakeholders and to the business.  There is nothing worse than working long and hard on something that never gets used, or has no value.

The daily scrum

So now that everything is planned, we can kick off our first sprint.  Most Agile teams will have a daily standup meeting.  The daily standup (or scrum) is a chance for each member of the team to briefly talk about what they are doing, what they plan to do, and any impediments or obstacles to their achieving these goals.  These are sometimes referred to as The Three Questions.  It isn’t a status meeting.  It’s a chance to share technical news, and other team members are encouraged to share information that can help other members of the team.  The daily standup can be run in a number of different ways, and there are a lot of mistakes that you can make in how you conduct these meetings.

Most people suggest running these daily standup meetings in front of the scrum taskboard.  You can do this with IDS by using the Team work view.  Just go to the original sprint planning view, and look at the nav bar on the left.  In the nav bar, there is an entry for “Team’s Work”, click on it and you will see the team view of the work in your sprint.

Scrum task board - with viewing options highlighted

Scrum task board – with viewing options highlighted

By choosing the viewing option icons at the top right of the view, you can look at your work as a list, as a table, or in lanes.  Most mature scrum teams will choose to view things in lanes.  If you look at your view, you will notice a lane for open work items (which have not started), and In Progress work items (which are currently being worked on).  If you look closely, there is a horizontal slider at the bottom of this view, and you can scroll to the right and see a lane for completed items as well.  Make minor updates to the taskboard as you go, as long as it doesn’t impact the meeting.  You can drag and drop work items between the lanes, and you can update the attributes if needed.

During the standup meeting, members should be notifying others of their progress, what they plan to do next, and highlight any risks or impediments to their progress.    This not only makes every team member accountable to the team (who is going to stand up and say, “Today I am going to finalize my fantasy football lineup, and watch YouTube videos of kittens?“), it also helps team members to collaborate.  They can help each other with suggestions, short cuts, and help avoid known technical issues.  You want to foster a collaborative team environment, not a structured status reporting environment (filled with Scrum zombies).

Ending the sprint

As you get closer to the end of the sprint, most of your work items should be in the resolved column in your scrum board.  You should be seeing steady progress throughout the sprint.  Your sprint should end with a demonstration of running software that demonstrates the new functionality that has been implemented.  Once the stakeholders sign off on the implementation, your sprint is almost done.

At this point you should bring your team together and have a sprint retrospective.  Go out and create one more work item for your sprint (you should do this at the beginning of the sprint, so people don’t forget it at the end).  They type for the new work item should be “Retrospective”.  During the retrospective, the team should reflect on what they did well, what they struggled with, and what they can improve.  All of this information should be captured in the notes section of the Retrospective work item.  Once the retrospective is over, the Scrummaster may want to create some new work items to reflect things that the team can do in future sprints, that will improve overall team performance.

Often these retrospective observations will end up creating stories that do not serve an end user need, but instead that serve a development team need.  Some people have referred to this as technical debt, but there is some argument about how to best characterize this work.  Examples of stories coming from retrospectives may include the refactoring of portions of the code, development of automated testing scripts, implementation of build and delivery automation capabilities, and other related issues.  Often these “tech debt” stories are the ones that are pulled from the backlog when a team finishes their planned sprint work early, and is able to take on additional work within a sprint.

Wrapping Up

At this point we’ve done a quick overview of how scrum teams can use IDS to help organize and track their sprint planning and execution, how they can groom their backlogs, and do planning in a transparent manner so all stakeholders and team members can have a shared understanding of the goals and the progress of the scrum team during a sprint.

In our next article, we’ll touch on some more intermediate topics.  We’ll talk about how to effectively use dashboards with IDS, effective ways to work with code in IDS, and some small tips and tricks that can help your teams use IDS to deliver end user results that will make your customers smile.

UrbanCode Plugins – Where Do I Begin?

As a manager of a highly technical team, it can be tough to stay on top of everything that happens within my team.  Recently I have been seeing an increasing number of requests for UrbanCode Plugins, those nifty little add-ons that make UrbanCode extensible and much easier to use.  Now you can go and grab an already existing plugin from the UrbanCode Plugins site, because that site has about 336 of them (I just looked at the list today – by the time you read this the number will have changed).  The point is, there are a lot of existing plugins out there already.  Note that some of these are “community” plugins, meaning that they are community supported.

But what should you do if you need a plugin that has not already been developed?  Well…. you should go and create a plugin for yourself.  Where should you start?  One of my team members (Darrell Schrag – check out his blog, DevOps for Everyone) created an UrbanCode Deploy and UrbanCode Release Plugin workshop recently.  I knew about it, but never realized how much it could help our UrbanCode customers.  My mistake – this stuff is good!

It is part of the IBM UrbanCode Learning Circle, which is a great way to get yourself up to speed with UrbanCode.  It provides a roadmap for how you can become a self-taught DevOps guru (or at least proficient with the UrbanCode Deploy and UrbanCode Release tools).  The lab workbook is 150 pages of hands-on training, exposing you to all of the different facets of building your own UrbanCode plugin.  I know that 150 pages sounds like a lot, but you should be able to invest an afternoon and learn what you need to know about creating your own UrbanCode plugin.

If you still have questions, you can always go out to the UrbanCode Forum and ask the community for answers.  The forum is monitored by the IBM development and support teams, as well as by other UrbanCode users.  Just use the tags “urbancode” and “plugin” on your post, to make sure that the right people see your questions.  The key thing to remember is that you are not alone – there are plenty of other people who are trying to do similar things to what you want to do.  If you’re lucky, maybe there is someone who has already developed what you want.

 

 

Resume inflation – Welcome to the New World

In North America, there has been a lot of focus on the recent stories involving television newscasters/journalists who have “inflated” their resumes.  Brian Wiliams was the first big one, and is now facing a 6 month suspension for exaggerating claims for battlefield experiences during the Iraq conflict.  Now Bill O’Reilly is facing similar questioning of his claims of journalistic heroism during the Falkland’s war in 1982.  In both cases you see a massive outpouring of words and opinions on how these two men have lied, or embellished their experiences, in an effort to establish themselves in their profession.

The whole thing puts a small sour grin on my face.  In the technical world, we have been dealing with this for at least the last two decades.  For almost as long as I can remember, I have been talking to software vendors, software contractors, and people that I am looking to hire, and silently asking myself the same question, “Is this person telling me what they can do, or are they telling me what they think they can do?”.

In the software products field, it has become something of a game, where purchasers put the various solution vendors through a series of trials to demonstrate capability.  I have always jokingly referred to this as the “Vendor Olympics”.  The scary part is that these competitions are often decided on criteria that have little to do with technical capability, and more to do with trust.  “Can I trust this vendor to do what they tell me they are going to do?”, is often the most important question.  That type of thinking has led to organizations implementing flawed solutions, because, “nobody ever got fired for selecting IBM/Microsoft/Cisco“.  This kind of thinking leads organizations and individuals to indulge in some strange behaviors.

It leads organizations into “pushing the envelope” when looking to recruit talent.  “We’re an Agile development shop”, is a quote that you hear from almost any place looking to hire top talent.  Top talent wants to work with Agile, which emphasizes a degree of reasonable expectations on a developer.  If you go and look at the development methodologies in use at these places, you will find a mix of agile, waterfall, scrummerfall, eXtreme Programming (XP), and mass confusion.  They are telling you what they think they can be, and not really what they are.

Job seekers are just as bad.  I cannot begin to tell you how many candidates I have interviewed who claim to possess skills that they don’t really have.  I have had candidates tell me that they know Agile, and then struggle to tell me about how story points work.  These are the good candidates, because I can get to the truth with a few simple questions.  The tough ones are the people who claim to have deep technical skills with REST, HEAT, Cloud, Enterprise software, and other things that I cannot ascertain with a few simple questions.

Why do they do it?  Have you LOOKED at the job posting boards out there?  Companies are looking for “perfect” fits, advertising jobs with a laundry list of critical skills, and HR organizations are looking for keywords in applicant resumes.  Do you have experience in complex technical sales involving Cloud solutions?  I do, but not many other people do.  Many are just as qualified as I am, they just need a minimal amount of time to learn some new concepts.  So in an effort to get through the HR screening process, many job seekers “inflate” their resumes, so they can get that initial conversation with a hiring manager.  It becomes a big game.

So why bother writing about this?  Because I am growing tired of having to play this game.  Don’t inflate your experiences, just tell me what you know and how deep you know it.  Don’t tell me, “oh yeah, I know Node”.  I would much rather hear about how you are familiar with Node, haven’t done any real projects with it, but are extremely interested in learning it.  I am tired of HR finding me “perfect” fits.  I want imperfect fits.  I want people who are going to be challenged, and who like learning and stretching themselves and their skills.  I value the following qualities over all else:

  • Honesty
  • Willingness to learn
  • Ability to learn

So I am imploring my HR staff, now and in the future, to quit finding me the perfect candidate, and to stop sifting through resumes looking for keywords.  I want to build flexible teams, with high trust cultures, that can rapidly become high performing teams.  If I can’t trust you to be honest on your resume, how can I trust you to do a quality job for me?  I do NOT want a bunch of specialists, who are as busy looking for their next position as they are in working on my project.  We need to stop the inefficient hiring games, and we need to get down to the business of actually creating something of value.  We need to reestablish trust in the workplace, and it all begins in the hiring process.

So be warned – if I catch a hint of resume inflation, I will not hire you.  Even if you would have been a good fit otherwise.  My three values are listed above – if you want to impress me, then demonstrate those values to me.

New Year’s Resolutions – Must Have Skills for 2015

My 2015 goals

(Note: My goal is pretty personal, so I have blanked out the picture here. Use your own picture, or even a cartoon, to illustrate what is important to you.

(Note: I was asked by the folks at Webucator to comment on what the most valuable workplace skill for 2015 would be.  I don’t know if I answered their question, but it did get me thinking….)

It’s a brand new year, and with the changing of the calendar, many of us take the time to make some resolutions for the new year.  For me, that means doing a couple of key things.  First, I have one big thing that I want to focus on and achieve in 2015.  I write this down in big letters, put a picture with it, and hang it up in my office.  It’s an old high school sports trick to make sure that you keep your goals in the front of your mind at all times.  I see it every day while I work, and see it up close each time I leave my office.  It’s a simple and effective way to make sure that I keep my focus on what is important to me in 2015.

The other thing that I do at the beginning of each year is to make a map of where I want my year to go,  To begin this, I take an inventory of my skills.  This is a simple list of the skills that I have, and if you keep something like this on LinkedIn (or some other social media), then most of the work is already done, because you have your list of skills from last year.  Just add the new things that you have learned.

Next think about where you would like to be in the next year or two.  This is part of your professional goal for the year.  What kinds of things do you want to be doing?  Where would you like to be?  What technologies interest you?  Take some time and think about this, because this is important.

Now we get to the heart of the matter, and we begin to look at the skills that you want to grow in 2015.  This part requires some work.  It requires some reading, and it requires some thinking.  Many people struggle with that “thinking” piece.  Most of us spend our days reacting to new events and new information, and just reacting to life in general.  For this part, you need to consume information, digest it and it’s meaning, and then reflect on what you have read.  It means that you have to slow down, and really think about things.

So where do we start doing some digging for the skills in general demand for 2015?  Start close to home and talk to your boss, your co-workers, and technical leaders that you know.  All of them have opinions and some idea of the things that will be important for the coming year.  Are you still in school?  Then ask your professors, classmates, and any technical leaders that you know.  This also helps you to network and build positive relationships in your current work environment.  People will talk to you, because everyone feels flattered that you find their ideas and opinions important.  Listen to them, and take notes.

The next thing to do is a little bit of good old-fashioned web searching.  Look for articles and blog posts (like this one) that talk about important skills for the future.  I’ve read more of these things than I care to remember, but as I read them I notice some common themes coming to the forefront.  Good places to start include Cybercoders, ComputerWorld, Infoworld, and Forbes.  Some might find my putting Forbes on the list a little strange, but the real value in software is where software can have positive business implications in the real world.  Forbes gives you a real business perspective on things, and that is important in the current software environment.

After doing all of this, I had my list of areas and skills that I think will be important in 2015.  I then matched this up against my own skills, and my long term desires.  I now have a list of areas that I think I would like to pursue, and the skills that I need to grow to be able to pursue them.  With this knowledge in hand, I can now create a second poster for my wall to remind me about the important skills and opportunities that I want to be on the lookout for in 2015.

So what skills do I have in my list?  Which skills do I think are important for 2015?  I have two big ones:

  • Cloud technology – everyone is talking about how “Cloud” makes everything better.  Not too many people can tell you WHY, and even fewer can tell you HOW.  You will want to learn more about Cloud technologies (like Bluemix, Open Stack, Cloud Foundry, AWS, Docker, Azure, and others), and make sure that you get some real hands-on experience with them.  You want to be the guy who can tell people both WHY and HOW.
  • DevOps – DevOps is another “hot” area in recent months.  There are a lot of vendors with DevOps solutions, as well as some good open source alternatives.  That’s all wonderful – but you need to understand the concepts first, and how massive automation can lead to better software development.

So now you can take my two “most important skills” for 2015 and add them to your list of sources.  Go and look at other sources, talk to people, take some time to THINK, and come up with your own personal list that fits your current skills and where you want to be.  Make sure that you write your list down and make it part of your everyday routine – reminding yourself of the big picture.  Let me know what you come up with, because I am always looking for new sources of information and new viewpoints to help me refine MY list.

What is a Learning Circle?

“An education isn’t how much you have committed to memory, or even how much you know. It’s being able to differentiate between what you know and what you don’t.” – Anatole France

Recently I was alerted to the IBM Learning Circles.  I should say that I was re-alerted, because I had known about them, but had not gone out to look at them in quite some time.  I was pleasantly surprised at what I found.

In the old days (back when the calendar year began with the numbers “19”), I used to spend a fair amount of time travelling around and delivering training classes to our customers.  The classes might focus on how to effectively use some tools, or might just be on specific software development concepts.  It was fun interacting with customers and the end users of our technology, but it didn’t really scale so well.  It also took the people being trained out of circulation for the 2-5 days that the classes were being taught.

Fast forward to today.  The customers that I deal with cannot afford to take there developers out of circulation for days at a time.  Developers don’t want to learn things in a classroom, they want “just-in-time” training, and often research answers to their problems with web searches.  The pace of life for developers has increased, and the traditional training techniques just don’t cut it anymore.  This is what the IBM Learning Circles are trying to address.

So what is a learning circle?  It is a different way to approach training and enablement.  It is a collection of reviewed content, organized so end users can consume training content in smaller pieces.  More importantly, they can control when they train, and how much they train.  They can look for topics that address their specific problems.  They have the ability to create Personal Learning Roadmaps that give them a step-by-step guide to relevant training materials.  So now the training is not only “as you need it”, it’s also “as you want it”, “when you want it”, and tailored to your specific needs.  You even become a member of a community of people from around the world who are doing the same thing (learning about a particular topic) that you are doing.  It’s pretty cool.

Right now there are a bunch of learning circles out there.  There are circles for Agile Skills, Engineering Lifecycle Management (RELM), Test Automation and Service Virtualization (think Greenhat), and UrbanCode Deploy and Release (just to name a few).  So if you are considering deploying these solutions, it would be a good idea to check into these learning circles.  What do you have to lose?

 

Bluemix gets your deployments rolling, rolling, rolling…..

I recently spent some time with some of our most knowledgeable Bluemix people.  We were helping one of our customers explore the possibilities of Bluemix for their organization.  Dan Berg and Scott Rich are two of the sharper guys I know, and they were helping us.  Dan Berg came up with a great technique that enables “Blue/Green” (or rolling) deployments on Bluemix.

You can read his developerWorks article, Automate Rolling Deployments with IDS for Bluemix , and learn how to do this.  The code samples and public Bluemix project that he provides allow anyone to be able to expose this kind of capability for their Bluemix users.  I was going to post my version of the directions for doing rolling deployments in this blog article, but Dan’s is very clear and easy to follow.  He even has links to the Bluemix project with sample code, and links to a post on Blue/Green deployment.

The “meat” of this is the deploy.sh script, but there are changes to the build script (in Ant) as well.  The build script changes that he discusses will copy your updated deploy.sh script to the archiving directory.  This is important to remember (see below).  Dan discusses the deploy shell script, and you should pay particular attention to where you would add the binding of services to your new application.  The nice thing is that you can test this out in a QA pipeline deploy, before you even attempt to do something like this for real.

Just some words of caution as you go through this.  The first is that you need to remember that your build and deployment scripts are under Git control.  This is great, because it allows you to see changes in your scripts, and gives you the ability to rollback to a previous version if necessary.  It also means that as you change your scripts, you will need to COMMIT and PUSH your script changes.  I have made the mistake of editing my scripts in the web browser editor, and then wondering why the changes I make don’t seem to do anything.  It’s because my script changes have not been pushed into the cloud yet.  Another issue is that even after you have pushed your changes into the Git repository, you still need to build the application to get them to execute.  Why?  Because the copy of the deploy.sh script to the archive directory occurs during the build, and the auto-deploy runs from the archive directory.  This isn’t an issue if you have auto-deploy turned on, since the Git commit will automatically kick off a build, which then kicks off an automatic deployment.

The scripts work great.  Ina session with one of our customers last week, the students set up a test that exercised the application being deployed.  It was a simple application, and we just changed some of the titles on a web page.  We then implemented a rolling deployment, and did a push of our changes in Bluemix.  We could then watch as the changes were built, and then auto-deployed in Bluemix.  Their tests noted no interruption of service when we deployed our changes.  It was pretty cool.

 

 


No Nonsense Tech Talk Member

These are my PERSONAL views and observations

The postings on this site are my own and don't necessarily represent IBM's position, strategies or opinions. Anyone is free to use, copy, distribute, modify or sell the source code and other materials directly linked from dtoczala.wordpress.com and is provided "as is" without warranties. I am not responsible for any harm or damage caused to your computer, software or anything else caused by the material.

Recent Twitter Traffic


Follow

Get every new post delivered to your Inbox.

Join 270 other followers

%d bloggers like this: