de-DEen-GB
 
rss

Granikos Technology Blog

Microsoft Teams LogoMicrosoft Teams ist der zentrale Ort für die sichere und produktive Zusammenarbeit in Office 365.

Hier sind die interessantesten Informationen aus KW 41.

Blogs

 

Video

 

Training

 

Dokumentation

 

Mobile

 

Viel Spaß mit Microsoft Teams!

 

Sie interessieren sich für Microsoft Teams? Dann werden Sie Mitglied des Microsoft Teams Meetup Berlin

 

 

 

Weiterlesen »

Auf dem aOS Aachen September 2018 Event hat Luise Freese die Vorträge in ihren bekannten Sketchnotes festgehalten. 

Hier sind ihr Sktechnotes zu meinen beiden Sessions.

Migrating Legacy Public Folders to Modern Public Folders

Sketchnotes - Migrating Legacy Public Folders to Modern Public Folders

 

Modern Attachments with OneDrive

Sketchnotes - Modern Attachments with OneDrive

 

Wer die Ignite 2018 besucht, kann Luise Freese dort treffen. Sie ist Chief Community Sketcher der Konferenz in Orlando.

Links

 

Stay Connected

 

Weiterlesen »

OneDrive ermöglicht das sichere Teilen und die sichere Zusammenarbeit an Dokumenten. Und dies über die die Grenzen von Betriebssystemen und Endgeräten hinweg.

Die Möglichkeiten von OneDrive stehen in allen Client-Varianten zur Verfügung, jedoch unterscheiden sich die Anwendungen je nach Einsatzszenario.

Hier hilft Ihnen der neue OneDrive Quick Start Guide, der Ihnen auf vier Seiten schnell und übersichtlich die Funktionen näher bringt.

OneDrive Quick Start Guide

Themen des Quick Start Guide sind:

  • OneDrive Web Client
  • Mobile Client für iOS, Android und Windows 
  • Erstellung von Dateien und Ordner
  • Synchronisation von (ausgewählten) Dateien und Ordner
  • Teilen von Dateien
  • Datein auf Abruf (Files On-Demand)
  • Weiterführende LDinks  

Links

 

Viel Spaß mit OneDrive!

 

 

Weiterlesen »

The Program:

  • Implementation/migration of round about 25 instances with a Specific Laboratory Software, supporting ~30 laboratories world-wide
  • Reduce support cost per instance by standardization (for existing and added instances)
  • Development of a template ("foundation") containing common functionality which can be influenced by configuration. Integration of the foundation into all instances. Provide all instances in operation with the current version of the foundation on a regular basis.

 

The challenges:

  • 2-3 implementation projects parallel
    • Full scope not clear in the beginning
  • Increasing number of instances in operation
    • Regular update of foundation version necessary to keep them streamlined in order to reduce support cost
    • Requirements and bugfixes from systems in operation have to be included into foundation development process
  • Many and changing team members, part-time availability
    • Round about 12 team members (incl. development and support)
    • Changes due to boundary conditions triggered by external influences
    • 80% of people only part-time available for the program
  • High interdependency between ongoing projects and Systems which are already in in operation due to foundation development and shared resources.
  • Organization of communication process between projects and operation
  • Balancing individual business needs on one hand versus streamlined standard software on the other hand

 

Why agile:

  • Manage individual projects (introduction of new Software)
    • Decision for projects taken during run-time of the program
    • Sequence of projects changing
  • Manage user stories across projects (details not available at start of the program)
    • Each new project delivers a slightly differentiating list of user stories
    • Each instance in operation delivers additional stories
  • Manage process
    • Change process quite complex, adaptions to the process must be quickly implementable
       

 

The agile setup - how did we handle the challenges:

  • In fact the program has been setup before we got in touch with the standard Scrum process (See our blog: What is Scrum?). So we used other role names, but some of them have exactly - amongst others - the tasks defined for the standard Scrum roles.

 

Bild

 

Orange = Business, Green = IT

 

 

  • Scrum Master ~ Development Coordinator / Program QA
  • Product Owner
    • Program Manager
      • Overall Product Owner
    • Project Manager and Application Managers
      • Product Owner for particular instances -> Prioritization and review / testing of stories
      • Write User Stories
      • "Imitate" the end user for sprint releases
  • Global Change Manager
    • Scope definition for the foundation
    • Release management of the foundation
    • Organization of SME-Board
    • Prioritization
    • Product Owner for foundation
  • Architect
    • Knowledge of implementation framework
    • Sets up development guidelines and general implementation approach
    • Gives first estimation of requirements with a technical view
    • Better management of the large product backlog, due to technical understanding, prioritization estimation
  • Program QA
    • Set up of change management process for the program
    • Regular overall review of change management process
       
  • Additional meetings
    • Subject Matter Experts Board (SME) (bi-weekly)
      • Participants: Whole team
      • Reviews the requirements from a technical and functional point of view
      • Gives implementation recommendations as decision memo for the CAB (Change Advisory Board)
      • Discusses additional technical issues
    • Process Review Meeting (quarterly in the beginning, currently twice a year)
      • Participants: Whole team 

 

The experiences:

  • User stories: Definition of user stories dependent on target group, developing a template of user story definition fitting for all team member in different roles, with different views and different backgrounds is a time consuming task
  • Testing: Developing awareness for testing right after delivering of implemented user story took also lot of time and patience 
  • Definition of project related sprint releases is useful to get quick feedback and reduces the effort for project managers (not every project manager has to test each increment)
  • A clear definition of product ownership incl. responsibility for successful product delivery is important for a successful project

 

This was the last part of our small Series about Agile Project Management

The whole Series contains 4 pieces:

Agile Project Management – Basics (Part1)
Agile Project Management – What is SCRUM (Part2)
Agile Project Management – Agile Project Management in real Life (Part3)
Agile Project Management – Agile on the next Level – Program Management (Part4)

If you have any comments on our Articles, your Feedback is highly welcome.

 

 

Weiterlesen »

Agile Project Management in real Life

 

The Project:

  • Development of a new web shop
  • Bring this web shop to a new platform to enable further enhancements (old platform was outdated)

 

The challenges:

  • Very high amount of complex requirements
  • Dependencies to other projects and an overarching IT Strategy Program
  • Special regional processes and requirements
  • New, unknown platform and framework

 

Why agile:

  • Manage high amount of requirements (incomplete list at start of the project)
    • Start by collecting all requirements on a very high level
    • Refine requirements during the project in order to save time by not writing every detail at the beginning of the project
  • Able to react to decisions from the IT Strategy program and/or other projects
    • The Project had to start earlier than the program, so some program decisions were not made at the beginning of the project
  • No clear "customer" as it was an internal project, but end-users are external customers of the company

 

The agile setup - how did we handle the challenges:

  • Besides the standard Scrum roles (See our last blog entry: What is Scrum?), additional roles were part of the project

 

image

Orange = Business, Green = IT

 

  • Cross Regional Working Team = Group of colleagues from different Departments act as "customers"
    • Write User Stories
    • Review product and give feedback
    • "Imitate" the end user
  • IT Process Designer as an IT counterpart to the Business Product Owner
    • More technical knowledge
    • Understands and communicates technical problems
    • Also has a very good knowledge about the business processes
    • Better management of the big product backlog, due to technical understanding, prioritization estimation
  • Additional Role "Solution Architect"
    • Knowledge of new implementation framework
    • Sets up development guidelines and general implementation approach
    • Gives first estimation of requirements
    • Better management of the large product backlog, due to technical understanding, prioritization estimation

 

  • Additional meetings to manage backlog
    • Sprint Planning Preparation
      • Participants: Solution Architect, IT Process Designer and Product Owner
      • Prepare Sprint Planning, define Sprint goal and set a rough scope for the next Sprint
    • Backlog Refinement
      • Participants: Development Team, Solution Architect and IT Process Designer
      • Review high prioritized stories and refine them to a state where they can be implemented
      • Add details to stories and split them up into multiple stories if needed

 

The experiences:

  • First version of user stories were very unspecific and way too complex to be implemented straight away
    • It was clear from the beginning that stories have to be refined (see "Challenges of the project" - Point 1) - but the effort to get the stories to a point where they can actually be implemented was underestimated
    • Project progress became unclear because the team did not work on actual business user stories, because they were too unspecific and complex, but transferred them into technical stories
  • Stories had to be split up multiple times, overall structure of story clustering and complexity changed multiple times
  • Tools such as JIRA were great to track and manage the backlog and to document and share knowledge within the project team
  • Not everyone has had agile experience
    • Roles were not fully clarified at the beginning, therefore more communication between the roles was needed, to make sure everyone understood his responsibility
    • During the project each role developed and grew based on the experience
    • The roles later on took over responsibility and made decisions where needed

 

Despite the difficulties especially at the beginning of the project, it is still very well in time. This is caused by the fact that the team always kept working and the project was never unable to go on. Due to the agile nature of the project in time communication and transparency were possible!

 

This was the third part of our small Series about Agile Project Management. Look out for the next part which we are going to publish soon called "Agile Project Management – Agile on the next Level - Program Management"

The whole Series contains 4 pieces:

Agile Project Management – Basics (Part1)
Agile Project Management – What is SCRUM (Part2)
Agile Project Management – Agile Project Management in real Life (Part3)
Agile Project Management – Agile on the next Level – Program Management (Part4)

If you have any comments on our Articles, your Feedback is highly welcome.

 

 

Weiterlesen »